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

сущность покупателя будет иметь поведение. это соответствует DDD.

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

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

DDD не предназначено для хоумпейджей, форумов, и в принципе, интернет магазинов. эта методология, как и всё остальное, не является серебряной пулей, и не может решать всех задач. но там, где это необходимо, DDD себя отлично показывает.
Эванс, между прочим, об этом говорил.

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

в этом нет ничего сложного даже применяя DDD методологию.

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

не представляю, потому что нет ни условий, ни задачи. значит представлять нечего.
а для каждой конкретно задачи, существует отдельное, и не одно, решение.

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

преимущество применения DDD методологии в более красивом и структурированном объектно-ориентированном коде, который собой отражает проблему и её решение.
это же очевидно.
но я тебе уже советовал не заморачиваться, а продолжать использовать процедурный подход. он больше тебе подходит.

E>>тебе так кажется.
G>Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей.

DDD методология совершенно не обходит стороной пожелания пользователей. а наоборот. работает с ними на одном языке.
а ты что-то опять путаешь.

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

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

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

они могут быть чем угодно.
как выборками, в твоём случаи,
так и просто полем объекта, которое изменяется каждый раз с приходом/уходом денег. соответственно нам нет необходимости пересчитывать баланс каждый раз. мы можем использовать готовое значение в нашей модели. проще говоря, для примера, это будет состояние объекта "баланс".