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

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

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

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

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

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

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

  • Система заказов считывает из базы данных Системы хранения запаса: объект продукта в системе заказа сопоставляется с объединением таблицы продуктов в системе заказа и в таблице продуктов в системе хранения запасов или Объект Product Ordering System содержит другой объект под названием StockKeepingProduct, который имеет значения из системы хранения запаса. Это было бы легко выполнить проверку, но это должно было быть гарантировано, что система заказов никогда не будет записываться в базу данных системы хранения.

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

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

1 ответ

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

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

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

licensed under cc by-sa 3.0 with attribution.