Блог

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

Что ж, команда сомневается, что

1. Используйте шаблон состояния (один агрегат, одно хранилище) или
2. Используйте один агрегат/репозиторий для обработки каждого состояния заказа.

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

О чем ты думаешь?

В общем, DDD-это все о том, чтобы не загрязнять домен проблемами инфраструктуры; вопрос о том, хранятся ли разные агрегаты в одной и той же таблице, является проблемой инфраструктуры. До тех пор, пока репозиторий/хранилища способны выполнять свои обязательства, действуйте.

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