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

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

4 голосов
/ 29 июня 2011

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

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 02 июля 2011

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

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

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

...