🚀 Как организовать разработку, если вы попали в те самые 5-10% проектов, где действительно приходится строить космолёт с использованием DDD?

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

⚖️ И в этом месте возникает развилка. Здесь есть два принципиальных подхода. Первый - описанием должен заниматься кто-то из команды разработки, ведущий разработчик, тимлид или архитектор. Такой владелец сможет лучше учесть технические тонкости реализации. Сказать, когда агрегат стал слишком большим, чтобы его можно было скопировать целиком, а когда накладные расходы не оправдывают выделение его частей.

📚 Альтернатива - сделать аналитика владельцем модели. У такого подхода есть одно важное преимущество. Агрегаты опираются на инварианты - правила, которые всегда должны соблюдаться. И аналитик лучше других понимает варианты использования системы. Какие сущности используются вместе, а какие могут быть объединены общим инвариантом.

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

⚠️ Главное не позволять обсуждениям скатиться в коллективное принятие решений. Обсуждения не должны становиться самоцелью. Идеальной системы в DDD все равно не будет, вопрос лишь какой из компромиссов предпочтительнее. Финальное решение и ответственность за целостность модели должны оставаться за конкретным владельцем.