Ограниченная реализация контекста и дизайн

Скажем, у меня есть два ограниченных контекста: Контекст доставки и Контекст фактурирования. Каждый из этих контекстов должен знать о клиенте.

На уровне данных клиент представлен таблицей CustomerTbl в базе данных. Эта таблица состоит из всех необходимых столбцов, описывающих клиента.

Столбцы в CustomerTbl (упрощенные):

Name
PhysicalAddress
PaymentMethod

Контекст доставки связан с Name и PhysicalAddress, в то время как контекст фактуры связан с Name и PaymentMethod.

В контексте доставки я смоделировал агрегат Recipient:

Recipient теперь имеет свойства/значения объектов для Name и PhysicalAddress

В контексте фактурирования я смоделировал агрегат Payer:

Payer имеет свойства/значения объектов для Name и PaymentMethod

Оба агрегата Recipient и Payer полностью разделены границей контекста. У них также есть свои репозитории.

Вопросы:

Допустимо ли иметь несколько агрегатов (при условии, что они находятся в отдельных ограниченных контекстах), используя ту же "таблицу базы данных"?
Данные клиента, вероятно, понадобятся во многих более ограниченных контекстах. Не означает ли это много реализаций совокупности, репозитория и factory для каждого ограниченного контекста? В коде будет избыточность. Это не влияет на ремонтопригодность?
Допустимо ли иметь общие свойства для агрегатов? Примером может быть свойство клиента Name. Это также означает избыточный код проверки?

Ответ 1

Q & А

1) Допустимо ли иметь несколько агрегатов (при условии, что они находятся в отдельных ограниченных контекстах), используя ту же "таблицу базы данных"?

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

2) Данные клиента, вероятно, понадобятся во многих более ограниченных контекстах. Не означает ли это много реализаций совокупности, репозитория и factory для каждого ограниченного контекста? В коде будет избыточность. Это не влияет на ремонтопригодность?

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

3) Допустимо ли иметь общие свойства для агрегатов? Примером может быть свойство имени клиента. Это также означает избыточный код проверки?

Тот же ответ, что и вопрос 1. Что касается избыточности, как только у вас есть совместное ядро, вы можете просто разместить там свои классы валидатора.

О вашем конфликте между DRY и DDD:

Элегантный код не излишне отличает отличные принципы дизайна друг от друга. Обычно существует способ, который удовлетворяет принципам. Вы просто еще не нашли его, потому что либо вы недостаточно понимаете принципы, либо недостаточно разбираете свою проблему.

(если это звучит догматично, потому что разработка программного обеспечения на самом деле является религией)

Ответ 2

Ответы:

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

Но это другая история, если получатель и плательщик доступны для редактирования. Скорее всего, их можно модифицировать, и это вызывает эффект в ограниченных контекстах. Например, клиенту может потребоваться изменение адреса конкретного заказа на доставку, но совместное использование таблиц резцов может изменить все адреса заказов отгрузок клиентов без предварительного уведомления. Поэтому лучше использовать для них различное хранилище.

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