По ссылке — видео выступления для SpbDotNet на тему «Event Storming: избавляемся от предположений в коде» от 14 апреля. Видео на два с половиной часа =)
http://agilemindset.ru/event-storming-избавляемся-от-предположений/
http://agilemindset.ru/event-storming-избавляемся-от-предположений/
Agile Mindset
Event Storming: избавляемся от предположений в коде - Agile Mindset
Краткое введение в Event Storming с реальным примером и структура простейшего воркшопа, чтобы участники могли сразу попробовать технику
Фейсбук напомнил о написанном 5 лет назад :) Легаси Стрит :)
Когда мы говорим о том, какими микросервисы должны быть с концептуальной точки зрения, мы всегда держим в уме и повторяем как мантру: «слабая связанность» и «сильное сцепление». Всегда.
И маршируя по Legacy Street за переход к более гибкой архитектуре, на наших транспарантах будут именно словосочетания «слабая связанность» и «сильное сцепление» :)
Что главное? Возможность внесения изменений и развертывание сервиса без необходимости внесения изменений в любую другую часть системы. Оно же — Low Coupling.
Сильное сцепление (High Cohesion) — я, как кем бы я ни был, хочу, чтобы связанное поведение находилось в одном месте, внутри некой границы, которая имела бы как можно более слабую связь с другими границами.
Вот тут появляется ограниченный контекст (Bounded Context) или иначе — конкретная ответственность, обеспечиваемая четко обозначенными границами.
И если мы хотим перейти от монолита к микро, то мы сначала очень аккуратно выделяем контексты, определяем модель (внутреннюю для контекста), повышаем модульность системы. Уверены? Выносим модуль в сервис.
И думаем о сервисах в терминах бизнес-возможностей. Сначала «Чем контекст (модуль, сервис) занимается и какие услуги предоставляет?», затем «Что (какие данные, внутренние или из других контекстов) ему нужны?»
Когда мы говорим о том, какими микросервисы должны быть с концептуальной точки зрения, мы всегда держим в уме и повторяем как мантру: «слабая связанность» и «сильное сцепление». Всегда.
И маршируя по Legacy Street за переход к более гибкой архитектуре, на наших транспарантах будут именно словосочетания «слабая связанность» и «сильное сцепление» :)
Что главное? Возможность внесения изменений и развертывание сервиса без необходимости внесения изменений в любую другую часть системы. Оно же — Low Coupling.
Сильное сцепление (High Cohesion) — я, как кем бы я ни был, хочу, чтобы связанное поведение находилось в одном месте, внутри некой границы, которая имела бы как можно более слабую связь с другими границами.
Вот тут появляется ограниченный контекст (Bounded Context) или иначе — конкретная ответственность, обеспечиваемая четко обозначенными границами.
И если мы хотим перейти от монолита к микро, то мы сначала очень аккуратно выделяем контексты, определяем модель (внутреннюю для контекста), повышаем модульность системы. Уверены? Выносим модуль в сервис.
И думаем о сервисах в терминах бизнес-возможностей. Сначала «Чем контекст (модуль, сервис) занимается и какие услуги предоставляет?», затем «Что (какие данные, внутренние или из других контекстов) ему нужны?»
Есть идеальный код, а есть просто хорошо структурированный
Так вот, идеальный код — практически невозможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.
Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.
Статья от нетфликс о hexagonal architecture: https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749
Рассуждения Саймона Брауна на тему организации кода: https://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html
Кому интересна история - первая статья о hexagonal architecture (Alistair Cockburn): https://archive.is/5j2NI
Для любителей видео: https://www.youtube.com/playlist?list=PLGl1Jc8ErU1w27y8-7Gdcloy1tHO7NriL
Так вот, идеальный код — практически невозможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.
Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.
Статья от нетфликс о hexagonal architecture: https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749
Рассуждения Саймона Брауна на тему организации кода: https://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html
Кому интересна история - первая статья о hexagonal architecture (Alistair Cockburn): https://archive.is/5j2NI
Для любителей видео: https://www.youtube.com/playlist?list=PLGl1Jc8ErU1w27y8-7Gdcloy1tHO7NriL
После двух лет использования автор статьи перешел с istio на linkerd. Статья полезна тем, кто выбирает какой использовать service mesh.
https://link.medium.com/00ksLCz9Fgb
https://link.medium.com/00ksLCz9Fgb
Примерно в 3/4 продуктов, с которыми переходим на микросервисную архитектуру нет версионирования API, а внешние библиотеки и сервисы используются AS IS (не обернутые в интерфейсы), проникая, словно споры плесени в кодовую базу продукта и подменяя своими сущностями сущности предметной области самого продукта, создавая зависимости, образуя vendor lock. Вирусное поведение, только никакой касперский тут уже не спасет, только собственная голова =)
Так вот, в архитектуре есть очень важное правило, для микросервисов оно гипер-актуально: архитектура не должна зависеть от конкретной версии коммерческого продукта, инструмента или библиотеки. Если подобная зависимость существует (trade off =) ), архитектура должна быть такой, чтобы переход на другую версию был простым и недорогим.
В микросервисной архитектуре команды могут самостоятельно выбирать наиболее подходящий инструментарий для достижения требуемого бизнес-эффекта, так что если не договориться о методах снятия таких зависимостей можно неплохо попасть на vendor lock.
Так вот, в архитектуре есть очень важное правило, для микросервисов оно гипер-актуально: архитектура не должна зависеть от конкретной версии коммерческого продукта, инструмента или библиотеки. Если подобная зависимость существует (trade off =) ), архитектура должна быть такой, чтобы переход на другую версию был простым и недорогим.
В микросервисной архитектуре команды могут самостоятельно выбирать наиболее подходящий инструментарий для достижения требуемого бизнес-эффекта, так что если не договориться о методах снятия таких зависимостей можно неплохо попасть на vendor lock.
Ищем спикеров на ArchDays.ru
Мы взрослеем и в этом году расширяем скоуп тем, выходим за рамки микросервисной архитектуры.
По любым вопросам пишите в личку @sergey486 или в коментарии к этому сообщению.
Мы взрослеем и в этом году расширяем скоуп тем, выходим за рамки микросервисной архитектуры.
По любым вопросам пишите в личку @sergey486 или в коментарии к этому сообщению.
Вышел результат исследования stackoverflow «developer insights» за этот год.
https://insights.stackoverflow.com/survey/2021
https://insights.stackoverflow.com/survey/2021
Первого сентября собираемся на архитектурное Ката 👊
Это наше первое и пробное подобное мероприятие, поэтому начнем с самого простого формата и будем эволюционно развиваться.
Формат простой: 10-15 минут закрыть все вопросы по заданию, разбиваемся на малые группы на час (сессионные залы в zoom), возвращаемся в общий зал и презентуем результаты. Предварительно у каждого по 10 минут на презентацию результатов.
То есть это не «прийти и послушать», это «прийти и попроектировать».
Правильного ответа не будет. В архитектуре вообще нет правильных ответов, есть подходящие под некоторый контекст и не подходящие. Поучимся друг у друга, познакомимся, хорошо проведем время
Краткое описание тут: http://archtalks.ru/2021/08/28/архитектурное-ката-01-09-2021/
И тут (тут же обсуждение задания): https://miro.com/app/board/o9J_l0aYN3U=/
Нужна регистрация (простая, через стандартную форму зума).
Это наше первое и пробное подобное мероприятие, поэтому начнем с самого простого формата и будем эволюционно развиваться.
Формат простой: 10-15 минут закрыть все вопросы по заданию, разбиваемся на малые группы на час (сессионные залы в zoom), возвращаемся в общий зал и презентуем результаты. Предварительно у каждого по 10 минут на презентацию результатов.
То есть это не «прийти и послушать», это «прийти и попроектировать».
Правильного ответа не будет. В архитектуре вообще нет правильных ответов, есть подходящие под некоторый контекст и не подходящие. Поучимся друг у друга, познакомимся, хорошо проведем время
Краткое описание тут: http://archtalks.ru/2021/08/28/архитектурное-ката-01-09-2021/
И тут (тут же обсуждение задания): https://miro.com/app/board/o9J_l0aYN3U=/
Нужна регистрация (простая, через стандартную форму зума).
Как думаете, есть ли смысл в COTS-микросервисах? Может уже есть такие?
Да, решения на микросервисах есть (АБС, кредитные конвейеры), а вот так, чтобы продавались отдельные микросервисы?
Понятное дело, что они строятся под конкретную модель предметной области, но в устоявшихся индустриях есть стандартные термины и определения (bian в банковской сфере, своя терминология в авиации, в телекоме уже свои референсы появились), так что… «Маркетплейс, продающий микросервисы, на которых сам же и построен» – в целом не такое уж и фентези…
Да, решения на микросервисах есть (АБС, кредитные конвейеры), а вот так, чтобы продавались отдельные микросервисы?
Понятное дело, что они строятся под конкретную модель предметной области, но в устоявшихся индустриях есть стандартные термины и определения (bian в банковской сфере, своя терминология в авиации, в телекоме уже свои референсы появились), так что… «Маркетплейс, продающий микросервисы, на которых сам же и построен» – в целом не такое уж и фентези…
Хорошая статья про кеширование от AWS Senior Principal Engineer.
И интересный термин metastable distributed system внутри.
https://brooker.co.za/blog/2021/08/27/caches.html
И интересный термин metastable distributed system внутри.
https://brooker.co.za/blog/2021/08/27/caches.html
Микросервисы / распределенные системы
Первого сентября собираемся на архитектурное Ката 👊 Это наше первое и пробное подобное мероприятие, поэтому начнем с самого простого формата и будем эволюционно развиваться. Формат простой: 10-15 минут закрыть все вопросы по заданию, разбиваемся на малые…
Через 10 минут стартанем, уже собираемся
Микросервисы / распределенные системы
Первого сентября собираемся на архитектурное Ката 👊 Это наше первое и пробное подобное мероприятие, поэтому начнем с самого простого формата и будем эволюционно развиваться. Формат простой: 10-15 минут закрыть все вопросы по заданию, разбиваемся на малые…
Встреча прошла отлично, спасибо всем, кто пришел =)
Материалы
Доска в Miro со схемами и ссылками:
https://miro.com/app/board/o9J_l0aYN3U=/
Начальные вводные (по сути проговорил то, что на доске написано):
https://www.youtube.com/watch?v=u05iQ3wy7DQ
Презентации решений (в описании проставил временные метки):
https://www.youtube.com/watch?v=Qu3g_eiY4XA
Материалы
Доска в Miro со схемами и ссылками:
https://miro.com/app/board/o9J_l0aYN3U=/
Начальные вводные (по сути проговорил то, что на доске написано):
https://www.youtube.com/watch?v=u05iQ3wy7DQ
Презентации решений (в описании проставил временные метки):
https://www.youtube.com/watch?v=Qu3g_eiY4XA
Скоро ArchDays
Мы вовсю работаем над тем, чтобы выступления были крутыми и иногда необычными, а опыт, хоть и онлайн, но положительным =)
По промокоду microservices_arch скидка 30%
ArchDays.ru
Мы вовсю работаем над тем, чтобы выступления были крутыми и иногда необычными, а опыт, хоть и онлайн, но положительным =)
По промокоду microservices_arch скидка 30%
ArchDays.ru