В конце мая проводил мастер-класс по 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-мир. Делать софтверный проект годами по плану в комплексном домене (по Киневин) не выйдет, код сам по себе не имеет ценности, он нужен, только когда его предназначение совпадает с текущими бизнес-потребностями. И архитектура должна, конечно же, помогать.

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

Ссылки
https://architectelevator.com/transformation/agile_architecture/ - цикл статей Грегора Хопа.

https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/ - книга Ричардса и Форда.

Nick Tune (один из активнейших членов DDD-сообщества, соавтор книги PPP of DDD) развивает инструмент Bounded Context Canvas

Данный канвас пригоден не только для документирования принятых решений, но и для дизайна контекстов как такового.

Сейчас существует уже 4 версия. На мой взгляд компоновка канваса стала чище и позволяет увидеть намного больше.

Канвас доступен в Miroverse https://miro.com/miroverse/category/newly-added/the-bounded-context-canvas

Использовали? Поделитесь, своим опытом.

@anatoly_sorokin из Dodo Engineering написал статью на хабре https://habr.com/en/company/dododev/blog/523540/ Читайте, комментируйте, нажимайте колокольчик.

А уже завтра я выступаю на конференции DotFest с докладом про Bounded Contexts. Это несколько переработанный и переосмысленный доклад с последнего оффлайн-митапа в KasperskyLab. Регистрация еще открыта, но только платно (в начале был доступен вариант с бесплатным участием) https://2020.dotfest.ru/lecture/4

Если вы из мира .net, уверен найдете что-либо интересное: подобрался неплохой состав.

Еще через неделю, 23 октября на соседней конференции про свой опыт использования DDD расскажет @agratushniy https://2020.phpfest.ru/lecture/6

Часто встречаю вопросы “Как внедрить DDD?” или “В вашей компании все используют DDD?”.

Но прежде чем внедрять, необходимо выяснить, что такое DDD. И здесь нет однозначного и общепринятого понимания. Каждый вкладывает в этот термин свой набор атрибутов.

Сейчас многие утверждают, что DDD - это скорее философия и сообщество без явных границ. Что-то может использоваться в DDD-подходе, но необязательно быть признаком. Агрегаты, события, контексты и т.д. – все это мы можем увидеть и за пределами DDD.

Но что делает DDD тем самым подходом, отличным от остальных? Если выбирать что-то одно, то я выбрал бы “общение с экспертами”. Из необходимости этого общения вытекают такие практики как Ubiquitous Language, Event Storming и прочие. А что для вас DDD?

Матиас и Кенни дискутировали недавно об этом. В итоге сегодня пройдет панельная дискуссия Присоединяйтесь!