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

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

E>>в этом нет ничего сложного даже применяя DDD методологию.
G>Ну ты уже показал что сделать это по DDD и эффективно нельзя? Или можно?

конечно можно.

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

решение не менее простое.

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

не все можно выразить цифрами.

G>Кроме того "красивый и структурированный" ОО-код может вести к проблемам быстродейтсвия, это ты и сам показал.

иногда. но в большинстве случаев он легче масштабируется, что решает проблемы быстродействия.

G>Тогда в чем преимущество "красивости и структурированности"?

в том же, в чем и любого другого хорошего кода, конечно же.
неужели это так не очевидно?

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

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

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

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

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

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