Комментарии 3
Результатом правильного проектирования и реализации DDD являются 4 свойства бизнес-логики:
легко понять;
Статья является просто кричащим противоречием заявленному в статье.
Хотя да, если не накидаешь англицизмов, то начальство может понять, что смысла в предлагаемой "архитектуре" нет никакого.
Бизнес-логика состоит из:
бизнес-логики мутации состояния DDD сущности;
бизнес-логики валидации состояния DDD entity;
бизнес-логики создания DDD сущности.
Зачем здесь 4 раза повторено выражение "бизнес-логика"? Её здесь нет. Ни одной. Потому что бизнес-логика - это правила ведения бизнеса. В бизнесе никто не мутирует состояния секретарши, не успевшей провалидировать состояние принтера с целью создания новой сущности "отчёт". Там просто дают втык. И это всем понятно, в отличии от.
Притянутый за уши формализм скрывает только одно - полное непонимание реальной задачи. Никакими ссылками на кандидатские западных теоретиков (столь же далёких от бизнеса) это безобразие не скрыть. Зато можно подменить задачи бизнеса на абсолютно произвольно трактуемые формулировки, что даёт бесконечный простор для пиления зарплат за счёт ничего-не-деланья.
DDD для меня только начинается, но никак не пойму как сущность может инкапсулировать бизнес-логику? Валидацию - вполне себе может, а вот с бизнес-логикой хотелось бы увидеть примеры.
DDD, HEXAGON, HIBERNATE, не считая JOOQ. Часть 1