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

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

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

S>DDD предлагает подход, где эти связи отсутствуют, т.е. сложность проще контролировать. Т.е. изоляция на уровне дизайна\архитектуры. А не только в коде.
Сливание всего в кучу не означает что связи исчезли. ИМХО, в этом и проблема, что в 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)" без аргументов откуда это следует. Из моей практики я вижу строго наоборот, что разделние логики и данных уменьщает связанность и делает дизайн гибче, а код быстрее.