Является ли хорошей идеей разделять объекты значения между доменами? - PullRequest
Новая
       34

Является ли хорошей идеей разделять объекты значения между доменами?

2 голосов
/ 12 января 2012

Предположим, у нас есть два домена в системе: Orderdomain и Customerdomain.

Оба домена довольно сложны и велики, поэтому объединить их в один домен невозможно.

Но между ними есть деловые отношения.В каждом Заказе Заказчик выступает в качестве Заказчика.

У меня есть как минимум три решения.

  1. Сохранение customerId в качестве примитивного типа как для Order, так и для Customer.

  2. Создайте два объекта-значения OrderDomain.CustomerId и CustomerDomain.CustomerId.Убедитесь, что эти типы типов можно сравнить на равенство.

  3. Создайте третий компонент SharedValueObjects с valeobject CustomerId и используйте этот тип в обоих доменах

Какой из них предпочтительнее или вы можете придумать четвертый лучше?

1 Ответ

4 голосов
/ 06 февраля 2012

Я постараюсь ответить как на ваш общий вопрос об объектах-значениях, так и на более конкретный из ваших комментариев?

  1. Могут ли домены совместно использовать объекты-ценности?

Это зависит. В системе, над которой я сейчас работаю, у нас есть около 15 крупных сервисов, мы разделяем типы значений, такие как «EMailAddress», «PhoneNumber», «Money» и т. Д. Эти типы четко определены, и у нас нет проблем с совместным использованием, но я не будет делиться вещами только потому, что они могут использоваться где-то еще, смакуйте ваши общие типы значений для тех, которые фактически используются. При обмене вы платите цену общесистемной связи.

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

Нет. Я бы не стал, как отмечали другие, Клиент - это то, о чем кто-то, кто работает в домене заказов, знал бы и запрашивал данные. Если вы утверждаете, что «Клиент» и «Заказ» представляют два разных домена, чем я предполагаю, что домен «Клиент» является чем-то вроде CRM-данных? Если вы моделируете «Заказчик» и «Заказ» отдельно, то домен «Заказчик» не может содержать данные, которые требуются в вашем домене «Заказ», например, адрес для выставления счета. Я понимаю ваше возражение против жесткой связи и огромных графов объектов, но вы можете справиться с этим, убедившись, что в вашей системе разрешено использование нескольких «клиентов»; каждый «Клиент» представляет свой собственный набор данных и поведения в ограниченном контексте. Например, у вас может быть как сущность Customer в вашем CRM-домене, так и сущность Customer в вашем «Order» -домене (я предполагаю, что это действительно Ordering-домен, потому что «Order» звучит как сущность, а не инкапсулированный набор бизнесов). процессы). В вашем CRM-домене у клиента могут быть такие вещи, как: номера телефонов, контактные лица, почтовые адреса и т. Д.), В домене «Заказ» у вашего клиента, безусловно, будут заказы, и такие вещи, как платежный адрес и т. Д. Итак, подведем итог. : не создавайте клиента, у которого есть все, поместите его в свой собственный домен и удалите отношение к заказам, вы только уменьшаете размер графа вашего объекта.

...