DDD: путаница в отношении хранилища/доменных границ

Мой домен состоит из продуктов, отделов, классов, производителей, ежедневных продаж, HourlySales.DDD: путаница в отношении хранилища/доменных границ

У меня есть ProductRepository, который облегчает хранение/извлечение продуктов из хранилища.

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

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

DailySales.GetSalesByDepartment(dateTime) 
DailySales.GetSalesByClass(dateTime) 
DailySales.GetSalesByHour(dateTime)

Правильно ли иметь эти методы отслеживания продаж в своем собственном репозитории? Я на правильном пути?

источник

2013-06-16 NoPyGod

Это имеет смысл для меня. Вы можете изменить название методов, чтобы сделать его более выразительным, например DailySales.ByClass (...) См. Эту статью для более полезной информации об этом: http://philcalcado.com/2010/12/23/how- to-write-a-repository/ – Sounten

Поскольку домены настолько зависимы от контекста, некоторые ответы сложнее других. Тем не менее, я бы поставил статистику на стороне Query. Вероятно, вы не хотите рассчитывать статистику на лету, так как вы будете размещать какую-то тяжелую обработку в своей базе данных. Как правило, статистика должна быть денормализирована для быстрого доступа, где требуется только фильтрация.

Возможно, вы захотите взглянуть на CQRS, если вы этого еще не сделали.

источник

2013-06-17 06:49:09

Я могу сказать вам, что в проекте, над которым я работаю, мы уже немного это делаем. Например, вместо того, чтобы каждый день рассчитывать ежедневные продажи «на лету», мы фактически сохраняем «текущую сумму» ежедневных продаж, разделенных отделом, группой и т. Д. Внутри отдельной таблицы. Я считаю, что это более или менее то, что вы имеете в виду? Это репозиторий DailySales, который запрашивает эти денормализованные данные. Вот о чем мой вопрос. Мне просто трудно научиться «правильному пути» делать вещи в этом мире DDD. – NoPyGod

Это действительно соглашения об именах, а также местоположения классов, которые меня облизывают, а не сами понятия. Должен ли класс, который запрашивает эти денормализованные данные, называться репозиторием или должен ли он называться Query? DailySalesRepository/DailySalesQuery. Должен ли класс жить внутри слоя данных вместе с репозиториями? Должен ли быть интерфейс для DailySalesQuery, который живет внутри сборки инфраструктуры, что позволяет в будущем вносить изменения в базовую базу данных и т. Д. Это те виды вопросов, которые меня действительно навязывают. – NoPyGod

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

Хотя большинство запросов возвращают объект или коллекцию объектов, он также вписывается в концепции, чтобы вернуть некоторые типы сводных расчетов, такие как граф объекта, или сумму числового атрибута, который был намерение составителя модель должна быть подсчитана.
Eric Evans - Domain-Driven Design 

Это может рассматриваться как read model. Являются ли эти ежедневные объекты продаж используемыми в любом поведении модели домена? От них зависит какая-либо бизнес-логика? Если нет, может быть хорошей идеей разделить это на четкую модель чтения - в этот момент вы делаете первые шаги в CQRS.

источник

2013-06-17 09:46:01 MattDavey

DDD: путаница в отношении хранилища/доменных границ

ответ

Смежные вопросы