Комментарии 1
На практике конечная согласованность в модели DDD поддерживается следующим образов: во время выполнения команды для изменения данных агрегата публикуется доменное событие, которое доставляется одному или нескольким асинхронным подписчикам.Event Driven Design как раз — это единственный путь обеспечить чистоту модели в реальном проекте. К сожалению, такой дизайн обеспечивает худшую отслеживаемость логики, так как сразу не видно, что происходит после какого-то доменного действия (подписчики ведь неявны, в отличие от прямых вызовов).
В реальном коде намного понятнее прямые вызовы разных агрегатов в сервисном слое, но это «разъедает» чистоту архитектуры. Зато проще в разработке (и при написании, и после написания).
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Эффективная конструкция агрегата. Заставляем агрегаты работать вместе