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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это понятно, а как это будет выражаться в коде с точки зрения DDD?