Применение DDD в базу данных Northwind

Question

Я хотел бы сделать некоторые упражнения и применить DDD в мою модель домена, применяемую в базу данных Northwind. Даже если Northwind является примером, я думаю, что это было сделано, чтобы удовлетворить некоторые требования к «виртуальным бизнесам». Таким образом, цель состоит в том, чтобы иметь модель домена, которая уважает DDD, и данные хранятся в базе данных Northiwnd.

Рассмотрим эту модель постоянства EF:

_{(источник: developpeur.org.)}

Обратите внимание, что у нас есть только субъекты и двусторонние отношения. Я хотел бы иметь настоящий DM, который уважает DDD. Более того, моя модель DM не должна быть зеркалом моей базы данных

1. Как вы бы изменили отношения, чтобы иметь только односторонние отношения или два способа, когда это необходимо.

2. Есть ли какие-либо отношения на один или один ко многим, которые могут быть изменены на один на один?

3. Как бы вы смоделировали агрегаты?

4. Как насчет ценностей объектов, услуг и фабрик, если это необходимо?

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

Не стесняйтесь спрашивать детали, если мой вопрос не понятен.

Заранее спасибо.

Answer 1

В общем я искушал ответить Мю (В зенском смысле), потому что сценарий неверно из перспективы DDD. В DDD мы начинаем с бизнес-требований и экспертов домена и от тех, которые мы получаем Доменная модель.

Хотя это спорная точка, база данных является почти случайным артефактом бизнес-требований (почти всегда утверждает, что организации должны быть сохранены).

Это сказано, я постараюсь сделать все возможное.

В большинстве случаев порядок является довольно важным бизнес-объектом, и, очевидно, нам нужно знать о строках заказа, включая продукцию в каждой строке, поэтому нам понадобится ассоциация из строя заказа (order_detail) к продукту.

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

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

Dev: Мы создали эту ассоциацию от заказов на продукты, чтобы мы всегда знаем все о продуктах в определенном порядке.

Exp: Это звучит хорошо, но как насчет поставщика?

Dev: Это также включено.

Exp: Так что происходит, когда мы меняем поставщика для продукта?

Dev: Это будет неявно отражено в данных заказа, а также ...

Exp: Это не то, что мы хотим. Мы хотим, чтобы данные отражали порядок в то время, когда мы его отправили.

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

Такой случай может предложить сокращение ассоциации от линий заказа на продукцию в целом. Заказы должны проводить исторические (снимки) данные продукта, а не текущие данные продукта.

Мы можем даже договориться о ProductSnapshot Цена объекта что семантически зеркала Product Сущность Чтобы моделировать это в модели домена.

В целом, это кажется все более разумным для модели Order как совокупность сама и заказывает линии (с ProductSnapShots), но как насчет отношений между заказами и клиентами?

Как я в настоящее время понимаю ассоциации и агрегаты, Ассоциации определяют агрегаты. Отказ Учитывая заказ, мы хотели бы знать о клиенте? Скорее всего. Учитывая клиента, вы хотели бы знать о заказах? Наверное.

Это говорит о двухсторонних отношениях, которые делают Customer то Совокупный корень. Отказ Это означает, что у вас будет CustomerRepository, но нет OrderRepository. Отказ Каждый раз, когда вам нужен заказ, вы должны получить его через Customer.

В некоторых случаях это может иметь смысл, в то время как это может быть действительно неуклюжем в других ситуациях. Это действительно зависит от бизнес-требований ...

Вы можете рассмотреть вопрос о создании OrderRepository а также, но это вторгается в Customer Совокупный корень. Если вы это сделаете, он становится расплывчатым там, где лежит ответственность за заказ. Что произойдет, если вы настраиваете от того, чтобы клиент? Customer имеет список заказов, но все они заполняются в память, если вы прочитаете заказ из OrderRepository?

Вероятно, нет, но они могут быть, если вы читаете клиента от CustomerRepository. Отказ Точка вот этот анализ Совокупные корни Важно, и как только вы определили совокупность, вам придется придерживаться его и уважать его.

Это заставляет меня оказывать небольшие агрегаты на больших агрегатах, поэтому в этом примере я бы ограничивал совокупность Order и линии его заказа и не имеют отношения между Order а также Customer.

Не имея официальной ассоциации между Order а также Customer не значит, что мы не можем связать их вообще, но нам нужно явное Сервисы Чтобы дать нам все заказы для данного клиента. Мы не можем просто ориентироваться от одного к другому.