Насколько связанной должна быть модель предметной области? Должны ли все совокупные корни быть интерфейсами?

Question

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

Указывает ли Заказ на Клиента или на ICustomer ?

В этом посте упоминаетсяпроблемы с агрессивно разъединяющимися объектами и, кажется, не поощряют "выход за борт с [интерфейсами]".Однако я не понимаю, как я могу по-настоящему юнит-тестировать свои доменные сущности, если я не могу издеваться над другими сущностями, от которых они зависят, что требует слабой связи.

Я также не уверен, насколько реалистично хотеть модель предметной области, в которой можно поменять части.

Answer 1

Я не против использовать конкретных коллабораторов в юнит-тестах, когда коллаборационист:

1) Имеет полный набор модульных тестов, который четко определяет его поведение.

2) Не сложно организовать.

3) Не использует внешние ресурсы (или не нарушает ни одно из этих связанных указаний ).

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

Answer 2

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

Кроме того, перемещение максимально возможного поведения в Value Object поможет вам сделать вашу модель предметной области тестируемой, так как Value Value (которые по определению являются неизменяемыми) очень легко протестировать.

Answer 3

Модель домена включает интерфейсы для слабой связи объектов домена с постоянством.

Постоянство Сохраняется ваши объекты. Он знает ваш объект, чтобы сохранить их. Отказ от постоянства модели не даст вам ничего. Любые изменения в домене должны быть отражены в слое постоянства,

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

Я также не уверен, насколько реалистично хотеть модель предметной области, в которой можно поменять части.

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