Здравствуйте, AndrewJD, Вы писали:

S>>Еще раз: да, в каких-то случаях все будет 1 в 1. В самых, вероятно, простейших.
AJD>Я например утверждаю, что она такая же и для сложных случаев.

Да я не против, речь о контроле над сложностью -- внесение изменений, новый функционал и т.п.
В DDD утверждается, что если делать по "инструкции", то все будет ок.

S>>Там вся соль на картинке именно в связях,
S>>т.е. ребрах между сущностями в соотв. уровне. Вот эти связи и есть сложность, которую надо контролировать.
AJD>Количество связей плюс/минус одинаково ибо оно дикуется бизнес логикой, вопрос в том где эти связи располагаются.

Как я понял, в DDD эти связи стараются локализовать, изолировать.

S>>DDD предлагает подход, где эти связи отсутствуют, т.е. сложность проще контролировать. Т.е. изоляция на уровне дизайна\архитектуры. А не только в коде.
AJD>Сливание всего в кучу не означает что связи исчезли. ИМХО, в этом и проблема, что в DDD постулируется что это приводит к лучшему дизайну без доказательств. Даже в этой статье приводится "Aggregates allow us to encapsulate parts of our domain so our API becomes simpler and changes inside aggregates are easier to implement (we don’t need to analyse our changes impact on some other parts of the domain because it doesn’t exist)" без аргументов откуда это следует. Из моей практики я вижу строго наоборот, что разделние логики и данных уменьщает связанность и делает дизайн гибче, а код быстрее.

А что и как тут можно доказать? Задачи DDD -- уменьшение связанности за счет выделения AR, т.е.
чем меньше ребер (на любом уровне), тем лучше. В DDD утверждается, что если делать все по науке,
то ребра будут только в BL(domain service), внутри AR, край -- между AR.