DDD ограниченный контекстный сервис против интеграции базы данных

Question

2 ограниченных контекста, первый - «Каталог продуктов», второй - «Маркетинг».

Маркетинговый контекст зависит от каталога продуктов.

Маркетинг нуждается в конкретных данных из каталога продуктов.Я колеблюсь между двумя подходами:

1 - Сохраняйте данные в каталоге продуктов, создавайте сервисный интерфейс в каталоге продуктов, который предназначен для уникальной цели запроса данных для конкретного сценария использования.

2- Иметь процесс, который будет запрашивать данные из базы данных каталога продуктов и передавать только необходимую информацию (а также делать любые необходимые переводы модели) в маркетинговую базу данных.

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

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

Answer 1

Каталог продукции (ПК) находится в восходящем (США), а маркетинг (М) - в нисходящем (DS).

Если я не понимаю вас неправильно, в основном вы спрашиваете, стоит ли вам идти на интеграцию синхронизации (Вариант 1) или async (2).

Поскольку вы говорите, что M не требует данных в реальном времени с ПК, возможно, мне следует перейти к асинхронной интеграции.Но я бы сделал это не через интеграцию БД, а с событиями:

Американский контекст (ПК) публикует события (например, ProductWasCreated) каждый раз, когда происходит изменение данных, и контекст DS (М) подписываетсяи ответьте (вставьте продукт в его базу данных).

О подходе (1), я думаю, что в ПК нет проблем с предложением услуг, в которых нуждается М.Служба должна обслуживать то, что нужно клиентам, не имело бы смысла, что ограниченный контекст предлагал бы то, что никто не хочет.В любом случае все зависит от взаимоотношений между командами (клиент / поставщик, партнерство, ...)

Вам следует взглянуть на различные типы сопоставления контекста (например, в Красной книге Vauhgn Vernon).).