Интеграция между различными доменными системами проектирования

Question

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

Например, возьмите следующие системы:

Объекты системы склада / хранения могут включать "Продукт", который будет иметь такие свойства, как "Количество", "Местоположение"

Объекты системы онлайн-заказа включают "Order", "OrderLine" и "Basket". Будет ли у него также свой собственный объект Product, который будет иметь такие свойства, как "Цена"?

Одно четкое бизнес-правило для Системы заказов заключается в том, что заказ не может быть размещен для товара, которого нет в наличии, но эта информация находится в Системе хранения запасов. Из того, что я понимаю, это несколько возможных способов реализации этого:

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

2. Система заказов считывает данные из базы данных системы учета запасов: сущность Продукт в системе заказов сопоставляется с объединением таблицы "Продукт" в системе заказов и таблицы "Продукт" в системе учета запасов, или сущность "Продукт системы заказов" содержит другая сущность под названием Stock KeepingProduct, которая имеет значения из системы хранения запасов. Это было бы легко выполнить проверку, но это должно быть обеспечено, чтобы система заказов никогда не записывала данные в базу данных системы хранения запасов.

3. Количество запаса денормализуется в базе данных системы заказов, и всякий раз, когда запас системы хранения запасов изменяется, она отправляет сообщение в систему заказов для обновления своего запаса.

Вероятно, в глубине души я знаю, что должен делать 3, но я не уверен, что мы вполне готовы к обработке такого большого количества избыточных данных и возможных несоответствий. Что вы думаете по поводу 1 и 2? Или у вас есть другие предложения?

Answer 1

Также все зависит от инфраструктуры. Если в одной сети работают 2 системы, следовательно, вероятность прерывания связи минимальна, я не вижу проблемы с решением 1. Вы можете обернуть вызов в Stock Keeping System в адаптеры и легко поменяться местами в будущем, если вы решите изменить API Stock Keeping System или система полностью как таковая. Кроме того, избегает утечки своих данных в систему заказов.

Решение 3 более продвинутое, требует больше ресурсов для внедрения и обслуживания, но позволяет полностью разделить эти две системы. Лучше справляется с перебоями в работе сети и узкими местами в производительности, например, в случае, если системе заказов необходимо обработать больше запросов, чем может обработать Stock Keeping System.

Но опять же это может быть реализовано так же, как 1) - разделены с помощью адаптеров. ИМХО с точки зрения DDD разницы нет.