Как по закону Конвея можно зафакапить внедрение DDD.
Мы пишем микросервисы. Дальше еще больше микросеврисов, затем еще и еще до того момента как общая картинка перестает умещаться в голове даже самого опытного инженера. А как мы знаем, любую архитектурную проблему можно решить дополнительным слоем абстракции. Появляется идея внедрить DDD.
DDD — не новая методология, о который мы тут не так часто говорим, но которая призвана, добавив слой абстракции (домены), снизить связанность, возвести заборы (bounded context) и открыть новые возможность масштабирования.
С помощью DDD хочется порешать сразу несколько проблем:
— Cильная связанность микросервисов.
— Отсутсвие Observability.
— Проблемы нечетких зон ответственности.
Дальше идут классические подходы к выделению доменов — задача декомпозируется, делегируется командам и те идут дизайнить свое виденье бизнес-сущностей.
В чем ту проблема? Стоит обратиться к классическому закону Конвея:
Современная его трактовка — «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации» (по версии Рут Малан).
Команды, исторически образовавшиеся в результате роста компании почти всегда уже поделены по четким зонам ответственности. Если внедрение DDD будет происходить через делегирование нарезание бизнес сущностей командам — вы с немалой вероятностью просто проделаете бюрократическую работу по описыванию зон ответственности, уже закрепленных за существующими командами.
Пример — сервис заказа пиццы. Одна команда отвечает за флоу создания заказа, другая — за его назначения курьеру. Делегировав командам описывать домены, можно получить две бизнес сущности об этом и том же — пользовательский заказ и заказ курьерский. То, что, возможно, одна бизнес сущность — заказ, разъедется по понятиям и не выделится в отдельный домен, а всего лишь подчеркнет текущее разделение между командами.
Редизайн системы нельзя рассматривать только с прикладных технических изменений и идеологий. Важно не только смочь правильно выделить основные сущности бизнеса, но и задуматься об организационной структуре команд. Редизайн системы без реорганизационных изменений с ненулевой вероятностью не взлетит.
https://www.uber.com/en-GB/blog/microservice-architecture/
https://cleverics.ru/digital/2020/12/conways-law-importance-teams-design/
Мы пишем микросервисы. Дальше еще больше микросеврисов, затем еще и еще до того момента как общая картинка перестает умещаться в голове даже самого опытного инженера. А как мы знаем, любую архитектурную проблему можно решить дополнительным слоем абстракции. Появляется идея внедрить DDD.
DDD — не новая методология, о который мы тут не так часто говорим, но которая призвана, добавив слой абстракции (домены), снизить связанность, возвести заборы (bounded context) и открыть новые возможность масштабирования.
С помощью DDD хочется порешать сразу несколько проблем:
— Cильная связанность микросервисов.
— Отсутсвие Observability.
— Проблемы нечетких зон ответственности.
Дальше идут классические подходы к выделению доменов — задача декомпозируется, делегируется командам и те идут дизайнить свое виденье бизнес-сущностей.
В чем ту проблема? Стоит обратиться к классическому закону Конвея:
Современная его трактовка — «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации» (по версии Рут Малан).
Команды, исторически образовавшиеся в результате роста компании почти всегда уже поделены по четким зонам ответственности. Если внедрение DDD будет происходить через делегирование нарезание бизнес сущностей командам — вы с немалой вероятностью просто проделаете бюрократическую работу по описыванию зон ответственности, уже закрепленных за существующими командами.
Пример — сервис заказа пиццы. Одна команда отвечает за флоу создания заказа, другая — за его назначения курьеру. Делегировав командам описывать домены, можно получить две бизнес сущности об этом и том же — пользовательский заказ и заказ курьерский. То, что, возможно, одна бизнес сущность — заказ, разъедется по понятиям и не выделится в отдельный домен, а всего лишь подчеркнет текущее разделение между командами.
Редизайн системы нельзя рассматривать только с прикладных технических изменений и идеологий. Важно не только смочь правильно выделить основные сущности бизнеса, но и задуматься об организационной структуре команд. Редизайн системы без реорганизационных изменений с ненулевой вероятностью не взлетит.
https://www.uber.com/en-GB/blog/microservice-architecture/
https://cleverics.ru/digital/2020/12/conways-law-importance-teams-design/