DDD - разделение / связь в ограниченном контексте

Question

Я пытаюсь использовать некоторые DDD подходы в приложении, которые позволяют покупку гостя. Хотя это выглядит легко, я немного запутался и попросил вашего DDD совета.

Приложение имеет несколько ограниченных контекстов, и мы рассмотрим 3 из них:

1. Клиенты (клиенты управляют своими пользовательскими настройками здесь, аутентификация, также администратор может потенциально создавать пользователей )

2. Продажа (заказы)

3. Биллинг (взимание с клиентов разовых платежей и подписок)

Пользовательская история: Как гость я хочу заказать продукт, чтобы он что-то сделал.

Это одна из форм, и при оформлении заказа ему / ей будет предложено указать адрес электронной почты и пароль. На этом шаге нам необходимо создать учетную запись, но на основе бизнес-логики c это соответствует контексту продаж - гость делает заказ. Нам на самом деле нужно сделать простые шаги:

1. Создать пользователя с АКТИВНЫМ статусом
2. Сохранить платежные данные
3. Создать заказ
4. Оплатить пользователя позже (событие обрабатывается Billing)

Путаница здесь заключается в том, что сначала требуется создать пользователя. Это выглядит более естественно, чтобы создать его у клиентов, но, возможно, это неправильно? Пользователь не может зарегистрироваться любым другим способом - только путем размещения заказа, но администратор может создать пользователя вручную. На основании разных системных событий (из разных контекстов) контекст Клиента может изменять статус пользователя на основе специального логика c, который помещается в домен Клиента. Есть ли какой-нибудь безопасный способ для обмена этими логинами статуса пользователя c между различными контекстами (при создании пользователя в Sales нам нужен этот класс перечисления статуса)? Этот лог c для размещения заказа выглядит нормально? Не могли бы вы порекомендовать другой подход, если считаете, что этот вариант неправильный?

Answer 1

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

По моему мнению, у вас есть следующие BC

• Идентификационные данные и пользователи
• Продажи и биллинг

считают это: тот же человек * User в первом контексте, но Customer в последнем. Таким образом, у вас есть два взгляда на одну и ту же сущность реального мира, которая предполагает, что у вас есть два ограниченных контекста, где эта сущность означает разные вещи.

ваши bcs звучат больше как модули в контексте Sales and Billing.

Если вы согласны, то поток управления для вашей проблемы может быть упрощен, если сущность в одном контексте создается, а создание распространяется через событие в другой. поэтому начальный запрос может быть обработан Sales b c, а обработка гостевого пользователя будет распространена на Identity.

Answer 2

Состояние в худшем случае DDD. В том числе поле состояния 1) ленивый и еще 2) очень удобный. Да, один из тех компромиссов дизайна.

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

Выкиньте status и вместо этого рассмотрите некоторые концепции : a CasualShopper или Гость (без покупок, просмотр товаров), PotentialNewShopper (кто-то добавляет вещи в свою корзину, которых вы никогда раньше не видели), и ваш обычный Клиент (который, вероятно, следует подразделить на основе их текущей активности).

С помощью этого смоделированного вы можете прикрепить поведение непосредственно к каждому из этих объектов, и само «состояние» сублимируется в более богатую DDD модель. Распространенной ошибкой DDD не является создание значимого с точки зрения транзакций объекта (например, роли Потенциальный покупатель ) для некоторого статического / невременного объекта (например, человека).

Отсюда вы можете решить, что вам нужно несколько ограниченных контекстов; возможно Потенциальные клиенты и Штатные клиенты . В каждом наборе доменных переходов различны и могут быть инкапсулированы, а не внешне.

Итак ...

С этим не похоже, что у вас есть Клиент B C и Возможный клиент B C. Вы можете безопасно делать то, что вам нужно сделать в последнем, теперь, когда оно автономно.

О, но это может повлиять на выставление счетов! и заказ!

Верно. Это может означать новые BC или новые объекты в таких BC, такие как ProvisionalPayment и UnauthenticatedOrder . Сейчас я немного болтаю ...

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

Выполнение всей этой работы означает не обмениваться небезопасным статусом , а обмениваться безопасными проекциями релевантных объектов * только 1054 *.

Кратко и неожиданно переходя к реализации, разработчики Не хотят хранить «временное» состояние. «Временное» состояние можно сохранять и необходимо, когда вы моделируете домен без этого поля cruddy status .