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

E>>>получили общую сумму покупок за последний месяц и передали доменной модели.
G>>Где получили? Кто получили?

E>тот, кто обращается к доменной модели.

E>>>так же эту сумму можно получить из объекта самого покупателя.
G>>Каким образом? Выполнить запрос к хранилищу? Покупатель будет иметь ссылку на repository?

E>покупатель будет сформирован с полным набором необходимых данных при помощи доменного сервиса.

Да, при помощи сервиса, а сущность "покупателя" будет DTO. Это уже похоже на нормальный дизайн.
А он соотвествует DDD?

G>>Или ты предложишь циклом ходить по orders, загружая всю историю заказов в память? и выполняя SELECT N+1

E>если доменная логика потребует проходиться циклом по ордерам, то так и будет.
E>и да, для этого необходимое кол-во ордеров будет загружено в память.
E>и да, вероятно будет select n+1.
E>это криминально? в бизнес приложениях — нет. в высоконагруженном сайте? возможно.

Значит DDD позволяет делать только тормозящее говно
Что и требовалось доказать.
Шучу конечно, но ощущение складывается именно такое.

E>>>всё зависит от организации модели.
G>>Ок, покажи как эффективно организовать модель в таком случае.

E>нужно исходить из задачи. а не абстрактного выдуманного примера.
Расчет скидки — не выдуманный пример.

E>и эффективная модель в каждом отдельном случаи будет различаться.
Представь что такой же код находится внутри CRM, где для каждого кастомера сотни заказов и десятки тысяч позиций.

E>>>ты их не видишь. другие их видят. не заморачивайся. возможно это придет, со временем. а возможно и нет.
G>>Так ты их назови хотя бы, а то даже с этим проблемы возникают.
E>преимущества в организации слоя бизнес логики, который отражает действительную проблему.
Так в чем это преимущество?
Ты сейчас пытаешься мне показать в случая с бухгалтерией построение слоя бизнес-логики, который как раз действительные проблемы не отражает.

E>>>мы и говорим на одном языке с экспертами. о тех вещах, которые нас интересуют. и не говорим о тех, которые нас не интересуют.
G>>Тогда вы делаете программу, которая нужна вам, а не пользователям.
G>>А обычно наоборот, слушают заказчиков\экспертов\пользователей.
E>тебе так кажется.
Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей.

E>>>DDD не имеет отношения к построению отчетов, точнее даже, обычных выборок.
G>>То есть не имеет отношение к домену (той самой предметной области о которой тебе скажут бухгалтеры).

E>отображение отчета какого либо отчета, совершенно никак не влияет на алгоритм расчета зарплат, под который мы делаем доменную модель, а значит, в данном случае, это нас не интересует.
А я не говорю про отображение, я говорю про получение данных. Баланс может и не отображаться, а сразу отправляться в налоговую.

E>>>ценность DDD в организации и построении бизнес логики.
G>>Так получение баланса и других данных для отчетов и есть та логика, которая нужна бизнесу. У тебя другое понимание бизнес-логики?
E>бизнесу нужна логика расчета данных, а их получение и отображение — это лишь следствие, и к логике никакого отношения уже не имеет.
Так я с этого и начал. Вот есть у бухгалтеров баланс, это не балансовая ведомость, а некоторые данные, соотвествующие определенным правилам. еще есть обороты, остатки — тоже наборы данных, формирующиеся по определенным правилам. Как и правильно отражать в программе с точки зрения DDD?
По сути они все являются выборками определенного вида.