Введение

К 2026 году с момента выхода «Голубой книги» Эрика Эванса прошло более 20 лет; 15 лет назад свет увидели «CQRS Documents» Грега Янга. В последующие годы вышло немало книг, посвящённых практическому применению принципов DDD и CQRS, таких как «Implementing Domain-Driven Design» Вона Вернона или «Patterns, Principles and Practices of Domain-Driven Design» Миллетта и Тьюна. Несмотря на столь долгий срок существования теории и немалое количество материалов, разработчик, решивший применить принципы DDD и CQRS на практике, постоянно сталкивается с вопросами, на которые он не может найти однозначных ответов. Stack Overflow нередко ограничивается намёками на решения, а появление искусственного интеллекта, порождающего противоречивые рекомендации, лишь усугубило ситуацию. Действительно ли нужно стремиться делать агрегаты как можно меньше и где проходит граница, за которой дальнейшее дробление уже не приносит пользы? Как разбить крупный агрегат, сохранив связи между сущностями? Должен ли агрегат содержать поля, подобные name или description, которые никак не влияют на его поведение? Содержит ли слой приложения доменную логику? Должны ли события быть «тонкими» и содержать только идентификаторы, или следует предпочесть «толстые» события, несущие контекст исполнения? В какой точке кода порождаются (оператор new) события? Если это делается в агрегате, то как организовать код в случае создания агрегата? Нужен ли репозиторию метод save? Где располагается код управления транзакцией? Должен ли слой приложения публиковать события? Где находится валидация команды в CQRS-архитектуре? Как организуется синхронная связь клиента и сервера, работающего по асинхронному принципу? Мы с коллегой тоже не были исключением: ответов на многие вопросы не было и у нас. Поэтому до фактического начала разработки нового проекта мы решили обобщить опыт, полученный в предыдущих проектах, и организовали ряд встреч, в ходе которых подолгу обсуждали свои предположения, пытаясь «протрясти» их и увидеть, где теория сталкивается с трудностями реализации. Со временем понимание DDD и CQRS росло, и многие практические задачи стали органично вписываться в архитектуру, которую мы параллельно разрабатывали. Все наши обсуждения мы фиксировали в записях, и именно ими мы и хотим поделиться с вами, читатель.