Pull to refresh

Comments 1

На практике конечная согласованность в модели DDD поддерживается следующим образов: во время выполнения команды для изменения данных агрегата публикуется доменное событие, которое доставляется одному или нескольким асинхронным подписчикам.
Event Driven Design как раз — это единственный путь обеспечить чистоту модели в реальном проекте. К сожалению, такой дизайн обеспечивает худшую отслеживаемость логики, так как сразу не видно, что происходит после какого-то доменного действия (подписчики ведь неявны, в отличие от прямых вызовов).
В реальном коде намного понятнее прямые вызовы разных агрегатов в сервисном слое, но это «разъедает» чистоту архитектуры. Зато проще в разработке (и при написании, и после написания).
Sign up to leave a comment.

Articles