Сегодня проводил онлайн мастер-класс про Event Storming на РИТ-фесте. Надеюсь было полезно. Для меня это был необычный опыт онлайн-конференции. Скоро будет запись.

А тем временем залил выступление @sergey486 про тот же Event Storming на февральском митапе в Райффайзенбанке. https://www.youtube.com/watch?v=kJjuTuviZ-E

Видеозапись доклада Алексея Тимченко о том, как Saga и Process Manager работают в message-driven среде готова к просмотру!

Приглашаем обсудить эту и другие DDD-темы в Кают-компании нашего сообщества.

Коллеги на конференции Техлид Конф выбрали амбициозную задачу: создание DDD техрадара.

Использование DDD требует изучения большого объема информации.
Множество статей и книг (с какой начать, синей или красной?) собирается в голове в обширную карту понятий и практик. А примеры зачастую отражают слишком упрощенную модель, поэтому по ним не всегда получается однозначно понять - а что же делать-то с реальными заказчиками?
Поэтому без достаточной практики легко допустить ошибки. На уровне архитектуры они как часовые бомбы - когда их обнаруживаешь, бывает уже слишком дорого переделывать.

На митапе нашей целью будет собрать бестиарий ошибок и анти-паттернов, о которых нужно знать практикующему DDD. Начинающему и опытному. 
Для этого мы будем собирать аналог техрадара, который регулярно составляет компания Thoughtworks. Но в нашем случае это будет радар подводных камней DDD. Мы обсудим проблемы, кластеризуем и отранжируем их в пространствах для онлайн-брейншторминга. Результаты будут визуализированы и оцифрованы на гитхабе, для последующего развития силами сообщества. Митап будут модерировать члены ПК.

Завтра будет первый подход, потом развитие сообществом. Не знаю, что из этого выйдет, но задумка точно интересная.

Если вы хотите поделиться своей экспертностью, и готовы завтра в 10-00 мск посвятить час закладке фундамента - пишите мне или Вьету (@stereohorse).

https://techleadconf.ru/2020/meetups#3011858

Приглашаем на очередную онлайн-встречу Domain-Driven Design Injection – 25 июня в 19:00!

Александр Евсюков расскажет, как, вдохновляясь DDD-классикой, дополнять её собственными находками. В частности, как избежать лишних передаточных звеньев при работе с агрегатами.

Регистрация: dddi.dev.

Друзья, наша итоговая встреча началась!
Чтобы присоединиться и пообщаться в Zoom – зарегистрируйтеcь на dddi.dev.

Послушать трансляцию также можно здесь.

В конце мая проводил мастер-класс по Event Storming. На РИТ фесте. Было очень необычно вещать в пустоту) https://www.youtube.com/watch?v=86_edESueds

В понедельник 20 июля будет проводится бесплатный воркшоп Первые шаги в DDD. Язык –английский, как я понимаю. https://www.meetup.com/Virtual-Domain-Driven-Design-meetup/events/271767297/

Если вы используете Miro, то возможно слышали, про запуск Miroverse. Miroverse позволяет поделиться с миром своим miro-шаблоном. Ник Тьюн так и сделал!

Держите четыре шаблона:

Core Domain Charts
Architecture Migration Core Domain Charts
Bounded Context Canvas
Domain Message Flowing Modelling

https://miro.com/miroverse/category/strategy-and-planning/strategic-domain-driven-design-template

@emacsway сделал классную подборку статей для погружения в Domain-Driven Design.

Сегодня в рамках Russian Python Week @slavabezborodov56 проводил встречу книжного клуба про Big Blue Book (https://conf.python.ru/moscow/2020/abstracts/7070).

Круто, что большие конференции смотрят в сторону DDD и проводят те или иные активности.

Отмечу, с сожалением, что тема DDD не вызывает больших дискуссий на этих конференциях. Возможно, что онлайн-формат накладывает свой отпечаток.

А как вам мир онлайн-конференций? Как часто участвуете, как смотрите доклады? Расскажите в чате, чего вам не хватает в текущих форматах?

Продолжим тему конференций и митапов.

Через неделю, 22 сентября сообщество системных архитекторов Райффайзенбанка приглашает на открытый онлайн-митап.

Константин Густов (@Kesteem) расскажет о своем опыте применения Domain-Driven Design, какие хорошие практики они используют, какие ошибки допускали и какие выводы из этого сделали.

Александр Лукашин (@kerhoff) расскажет о практиках, которые они используют для старта разработки в новых предметных областях. Подробно остановится на том, как могут помочь принципы Domain-Driven Design.

Подробное описание и регистрация https://raiffeisen-events.timepad.ru/event/1417351/

https://gradea.github.io/rpw.html

Рассказал на Russian Python Week об опыте использования тактических паттернов DDD. В процессе подготовки собрал ряд ссылок с интересными материалами. Как и обещал - публикую здесь презу и дополнительные материалы.

Кстати, если вы пишите на Python, то наверняка слышали про проект dry-python, который развивает Никита Соболев (@sobolev_nikita) и другие.

У проекта есть группа в Телеграме, присоединяйтесь! https://news.1rj.ru/str/drypython

Трансляция открытого митапа идет! Александр Лукашин (@kerhoff) уже отстрелялся, сейчас у микрофона Костя Густов.

Подключайтесь прямо сейчас https://facecast.net/v/1kkl5d

Отличное мероприятие организовали @Kesteem с коллегами.
Я в очередной раз убедился, что в случае онлайна уровень вовлеченности на специализированных ивентах на порядки выше, чем на общих конференциях.

Последнее время ухожу в сторону развития команд и процессов. Сложившаяся практика разделяет менеджмент с оргдизайном и процессами от архитектуры и разработки. Считается, что менеджеры создают структуру и мотивацию, а архитекторы и команды создают программный продукт.

Но нельзя забывать о Законе Конвея, согласно которому, архитектура проекта будет повторят структуру организации. Таким образом менеджмент влияет на крупноблочную компоновку проекта сильнее чем архитектор.

Сейчас чаще стали говорить про Закон Конвея, учитывать его при формировании структуры команд и закладывать мероприятия по изменению текущей оргструктуры в соответствии с целевой архитектурой.

При определении скоупа ответственности команд есть несколько подходов. Устоявшийся в DDD – за конкретный контекст отвечает одна команда, а иногда не только отвечает, но и вносит изменения. Такой подход объясняется тем, что контекст инкапсулирует логику и содержит в себе модель, единый язык, какие-то неявные предположения. Команда, незнакомая с контекстом легко разрушит консистентность модели и языка, что приведет к деградации контекста. Вернон в своей книге явно высказывается за такой подход.

Чем плох такой подход:
1. Зависимости при e2e реализации фичи. Обычно задачи не ограничиваются одним контекстом. Возникает необходимость менеджить зависимости.
2. Неоптимальная нагрузка: команда А может умирать, работая над критичным сервисом, а команда Б будет полировать сервис, который прямо сейчас особо и не нужен. При этом команда Б не может помочь, так как зачастую нет достаточной экспертизы.
3. Контексты могут фризиться и умирать. Появляются новые. Команды тоже могут умирать и появляться. Необходимо балансировать нагрузку.

С другой стороны есть подход фреймворка LeSS – все работают везде. Здесь плюсы и минусы просто переворачиваются. Отдельно хотелось бы отметить когнитивную нагрузку. Разработчикам может быть неэффективно и очень некомфортно работать над огромной кодовой базой.

Все вышесказанное уместно и для микросервисов.

А как у вас? Какой подход вам ближе? Как работаете с перечисленными недостатками? Какие плюсы и минусы видите еще?

Пост навеян статьей и книгой Team Topologies

Всегда интересовала роль архитектора в DDD и Agile ориентированной разработке. Такие фреймворки как Scrum и LeSS явно говорят, что не должно быть такой роли.
Многие авторы тем не менее выделяют такую роль, хотя оговаривают, что это именно роль, а не должность с погонами (анти-паттерн Ivory Tower Architect).

Что же должен делать архитектор, что мы ждем от него, какую добавленную ценность привносит в наш value stream? Что такое архитектура, в конце концов?

В древних манускриптах книгах можно встретить определение архитектуры, как нечто сложно и дорого меняемое. Но уместно ли говорить про дороговизну и сложность изменений в наше время микросервисов? Мы готовы переписать любой микросервис за месяц-два. Или архитектура это само решение использовать микросервисы? Тогда архитектор нужен только на старте проекта.

Мне очень отзывается пост Грегора Хопа, где он связывает необходимость частых изменений и готовность вашего проекта к этим изменениям. Собственно одна из задач архитектора подобрать такие подходы и решения, которые позволят недорого вносить изменения.

И DDD и Agile приветствуют вносимые изменения. Это наш реальный VUCA-мир. Делать софтверный проект годами по плану в комплексном домене (по Киневин) не выйдет, код сам по себе не имеет ценности, он нужен, только когда его предназначение совпадает с текущими бизнес-потребностями. И архитектура должна, конечно же, помогать.

Как у вас? Есть выделенные архитекторы? Как они работают с командой? Пишут ли они код? Насколько погружены в бизнес-домен?