Переводчик между ограниченными контекстами в DDD (и некоторые другие вопросы)

Я читал DDD Эрика Эванса: "Сложность решения в основе программного обеспечения", а в разделе "Контекстные карты" Эванс привел пример двух ограниченных контекстов (контекст бронирования и служба сетевого обхода) с использованием транслятора для их интеграции.

Если я правильно понимаю, когда мы создаем модель, мы помещаем все в ограниченный контекст, создавая концептуальные границы для области. Мои вопросы:

  1. Если все должно быть в ограниченном контексте, где должен располагаться переводчик? В образце диаграммы Эванса переводчик находится вне (между) обоих ограниченных контекстов.

  2. Скажем, у нас есть одна команда, работающая над ERP. Следует ли использовать ERP в нескольких ограниченных контекстах или только в одном. На основе выборки Эванса были разработаны ограниченные контексты, чтобы несколько команд могли работать над своей собственной моделью. Но так как это одна команда, разве они не выиграют от одной модели, чтобы интеграция не была проблемой? Или я неправильно это понял?

  3. В случае вопроса 2, если несколько ограниченных контекстов, что если в реализации нам нужен класс из Accounting, который будет использоваться в Payroll? Я не думаю, что нам нужен переводчик, но я не уверен, как разделить требуемый класс. Будет ли просто ссылка на нужный класс из другого ограниченного контекста?

  4. И, наконец, как модуль в DDD связан с ограниченным контекстом?

Источник

2 ответа

Решение

  1. На уровне инфраструктуры (вне домена) это техническая деталь.

  2. Ограниченный контекст (BC) возникает из домена, поэтому мы их идентифицируем, а не определяем. После определения, если есть много BC и есть разработчики, тогда рабочая нагрузка может быть разделена так, чтобы приложение могло быть разработано быстрее. Не рекомендуется использовать одну модель, вам нужна модель одного домена на BC, а также упрощенная модель чтения для запросов (CQRS).

  3. Я не знаю, но для меня Заработная плата является частью учета, на самом деле нет 2 до н.э. Учетная запись - это БК, однако другим БК может потребоваться расчет заработной платы, но это определение относится к БК. И, вероятно, определение - это просто некоторые данные (модель чтения). Поведение заработной платы должно оставаться в бухгалтерском учете. Таким образом, вы должны четко определить, что каждый БК понимает под "платежной ведомостью". Обычно у вас есть доменная служба, которая будет использовать понятия как из BC, так и с помощью "переводчика".

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

Источник
  1. Если все должно быть в ограниченном контексте, где должен располагаться переводчик? В образце диаграммы Эванса переводчик находится вне (между) обоих ограниченных контекстов.

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

  1. Скажем, у нас есть одна команда, работающая над ERP. Следует ли использовать ERP в нескольких ограниченных контекстах или только в одном. На основе выборки Эванса были разработаны ограниченные контексты, чтобы несколько команд могли работать над своей собственной моделью. Но так как это одна команда, разве они не выиграют от одной модели, чтобы интеграция не была проблемой? Или я неправильно это понял?

Я думаю, что вы поняли неправильно. Вы разделяете одну модель на несколько BC в соответствии с UL, а не на доступные команды. Тогда, если у вас недостаточно команд для количества созданных БК, команде придется разработать более одного БК. Кстати, обратное нежелательно, т. Е. БК не должен разрабатываться более чем одной командой.

  1. В случае вопроса 2, если несколько ограниченных контекстов, что если в реализации нам нужен класс из Accounting, который будет использоваться в Payroll? Я не думаю, что нам нужен переводчик, но я не уверен, как разделить требуемый класс. Будет ли просто ссылка на нужный класс из другого ограниченного контекста?

Вы не должны ссылаться на объект домена другого BC. Этот BC должен защищать свою модель предметной области, для которой это прикладной уровень. Прикладной уровень предоставляет DTO, простые объекты, он не должен предоставлять модель предметной области внешнему миру. То, что вы просите, - это общее ядро ​​(модель, используемая другими BC).

  1. И, наконец, как модуль в DDD связан с ограниченным контекстом?

Модуль - это просто пакет Java, полезный для хранения вещей, которые связаны друг с другом. Таким образом, вы разделяете исходный код BC на модули. Делайте это согласно UL, а не техническим аспектам. Например, модуль для каждого агрегата, а не модуль для сущностей, другой для хранилищ и т. Д.

Источник
Другие вопросы по тегам