Сообщение Re[24]: DDD протаскивание других слоев через параметры метод от 09.12.2020 18:40
Изменено 09.12.2020 19:02 AndrewJD
Re[24]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, Sharov, Вы писали:
S>Еще раз: да, в каких-то случаях все будет 1 в 1. В самых, вероятно, простейших.
Я например утверждаю, что она такая же и для сложных случаев.
S>Там вся соль на картинке именно в связях,
S>т.е. ребрах между сущностями в соотв. уровне. Вот эти связи и есть сложность, которую надо контролировать.
Количество связей плюс/минус одинаково ибо оно дикуется бизнес логикой, вопрос в том где эти связи располагаются.
S>DDD предлагает подход, где эти связи отсутствуют, т.е. сложность проще контролировать. Т.е. изоляция на уровне дизайна\архитектуры. А не только в коде.
Сливание всего в кучу не означает что связи исчезли.
S>Еще раз: да, в каких-то случаях все будет 1 в 1. В самых, вероятно, простейших.
Я например утверждаю, что она такая же и для сложных случаев.
S>Там вся соль на картинке именно в связях,
S>т.е. ребрах между сущностями в соотв. уровне. Вот эти связи и есть сложность, которую надо контролировать.
Количество связей плюс/минус одинаково ибо оно дикуется бизнес логикой, вопрос в том где эти связи располагаются.
S>DDD предлагает подход, где эти связи отсутствуют, т.е. сложность проще контролировать. Т.е. изоляция на уровне дизайна\архитектуры. А не только в коде.
Сливание всего в кучу не означает что связи исчезли.
Re[24]: DDD протаскивание других слоев через параметры метод
Здравствуйте, 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)" без аргументов откуда это следует. Из моей практики я вижу строго наоборот, что разделние логики и данных уменьщает связанность и делает дизайн гибче, а код быстрее.
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)" без аргументов откуда это следует. Из моей практики я вижу строго наоборот, что разделние логики и данных уменьщает связанность и делает дизайн гибче, а код быстрее.