А формироваться этот список должен внутри доменной модели, котороя знает как наиболее оптимальным образом вытащить эти данные из базы или еще откуда.
Не согласен, потому что доменной модели должно быть все равно на отображение, и оптимальности на этом уровне никакой нет.
В крайнем случае этот список может формировать фасад…
Именно так я и понял из вашей статьи, но фасад скрывает доменную модель, которая содержит данные и бизнес-логику. Если вы знакомы с DDD, то понимаете, что репозиторий PersonRepository, возвращает АГРЕГАТ — Person, а он состоит из 5-ти объектов, следовательно 5 * 10 = 50!
Спасибо большое за статью, очень интересно написано и слог хороший. Я понимаю что доменная модель предназначена для реализации бизнес-логики. Если я правильно понял, Вы предлагаете использовать над ней некий ФАСАД упрощающий отображение во View. Но вот самый простой пример, я использую DDD (Domain Driven Design), и у меня есть АГРЕГАТ Person (человек), который состоит еще из пяти объектов. Нужно отобразить список Ф.И.О. 10 человек, 1 человек = 5 объектов, как-то нелогично тянуть из БД 50 объектов, чтоьы отобразить такой простой список.
Не согласен, потому что доменной модели должно быть все равно на отображение, и оптимальности на этом уровне никакой нет.
Именно так я и понял из вашей статьи, но фасад скрывает доменную модель, которая содержит данные и бизнес-логику. Если вы знакомы с DDD, то понимаете, что репозиторий PersonRepository, возвращает АГРЕГАТ — Person, а он состоит из 5-ти объектов, следовательно 5 * 10 = 50!