Кстати, если вы пишите на 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?

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

Про давление сроков.

На мой взгляд это одна из причин наших Big Ball of Mud.

Чарльз Лехт уже нас предупреждал более 50 лет назад: Разработчик будет “обязан согласиться из уважения, страха или ложной лояльности” и неохотно, но соглашается на эти сроки. Разработчик открывает свой секретный ящик с инструментами и делает всё возможное, чтобы успеть к ближайшему сроку, используя инструменты, такие, как хардкод, копипаст-программирование, игнорирование тестов, сверхурочные и другие, разрушающие качество и срезающие углы практики см. книгу The Enterprise and Scrum. Никто не обращает внимание на использование этих ‘инструментов’, поэтому что сроки соблюдены. Менеджмент награждает разработчиков за их тяжёлый труд и восхваляет их за “отличную командную работу” и “боевой дух”.

Мне нравится, что Канбан метод и #noestimate опосредованно позволяют избегать этой проблемы.

Ребята перевели отличную статью про работу с легаси кодом. http://blog.agilix.ru/2020/10/28/%D1%83%D0%BD%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9-%D0%BA%D0%BE%D0%B4/

Отличный (хотя и немного капитанский) доклад Сэма Ньюмена про сокрытие информации.

Очень понравилась часть про coupling: он делит на несколько видов и выстраивает их в иерархию от самой слабой связанности на уровне домена до самой сильной на уровне контента. Я раньше в голове не делил по видам, хотя подсознательно понимал эти степени.

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

Ограниченные контексты и агрегаты как раз и направлены на то что скрыть информацию, а то что не скрыто показать явно. Для меня теперь любая анемичная дырявая модель – пример content coupling (aka Pathological coupling): ни контракта, ни инвариантов, никакой явности, даже семантика полей разъезжается иной раз.

Сделал майндмап, можно пробежаться по основным тезисам прежде чем смотреть доклад целиком.

P.S. не смог нагуглить быстро про Tramp Coupling – знаете, что это такое?

Небольшой опрос, приключение на пару минут https://www.menti.com/8ek7z9uxrk

UPD Пробелы ставить можно и нужно!)

Агрегаты и контексты – наше всё!)

Коллеги, завтра в рамках онлайн митапа по PHP будет доклад на тему DDD. Участие бесплатное https://simbirsoft.timepad.ru/event/1467649/

Сегодня рассказывал про агрегаты на Archdays2020. Примеры кода и референсы доступны по ссылке. Репозиторий будет обновляться.

Поделился своим видением на Domain-Driven Design
Заодно похрустели пиццей на камеру 🍕🍕🍕
https://www.youtube.com/watch?v=I0WI28QmjCc

P.S. Подготовка нового мероприятия в полном разгаре, stay tuned, скоро будет анонс!