Как по закону Конвея можно зафакапить внедрение DDD.

Мы пишем микросервисы. Дальше еще больше микросеврисов, затем еще и еще до того момента как общая картинка перестает умещаться в голове даже самого опытного инженера. А как мы знаем, любую архитектурную проблему можно решить дополнительным слоем абстракции. Появляется идея внедрить DDD.

DDD — не новая методология, о который мы тут не так часто говорим, но которая призвана, добавив слой абстракции (домены), снизить связанность, возвести заборы (bounded context) и открыть новые возможность масштабирования.

С помощью DDD хочется порешать сразу несколько проблем:

— Cильная связанность микросервисов.
— Отсутсвие Observability.
— Проблемы нечетких зон ответственности.

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

В чем ту проблема? Стоит обратиться к классическому закону Конвея:

Современная его трактовка  — «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации»

(по версии Рут Малан).

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

http://sewiki.ru/Категория:Практикиорганизационногоразвития

Пример — сервис заказа пиццы. Одна команда отвечает за флоу создания заказа, другая — за его назначения курьеру. Делегировав командам описывать домены, можно получить две бизнес сущности об этом и том же — пользовательский заказ и заказ курьерский. То, что, возможно, одна бизнес сущность — заказ, разъедется по понятиям и не выделится в отдельный домен, а всего лишь подчеркнет текущее разделение между командами.

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

Материалы по теме:
https://www.uber.com/en-GB/blog/microservice-architecture/
https://cleverics.ru/digital/2020/12/conways-law-importance-teams-design/

Пост в Telegram: https://t.me/startup_architecture/83