DDD - проверка существования сущности в других ограниченных контекстах

Question

У меня есть вопрос относительно того, что лучше всего делать, когда дело доходит до проверки существования сущностей в ограниченном контексте. Это даже правильный подход в DDD? B C должны быть автономными развертываниями (т. Е. Вы не должны зависеть от того, что другой B C может быть недоступен).

У меня есть 2 B C в моем проекте - Ингредиенты и рецепты , Компания продает сыпучие ингредиенты, а также готовые рецепты с использованием указанных ингредиентов. Теперь это отдельные B C, каждый со своим составным элементом.

Рецепт - это совокупность root, в которой есть дочерняя сущность из списка ингредиентов. Имеет ли смысл проверять наличие ингредиента в Ингредиенте B C перед добавлением его в список ингредиентов в Рецепт B C?

Ингредиенты могут быть изменены только через ингредиент B C, где будут публиковаться события и рецепт B C будет подписываться и обновлять свои собственные ингредиенты для любых изменений (например, цена / название). Для того, чтобы это было действительным, ингредиент должен быть действительным. Итак, как мне поддерживать согласованность между этими B C? Нужно ли вводить доменную службу в рецепт B C и проверять наличие ингредиентов перед их добавлением? Я также использую CQRS, чтобы я мог внедрить службу непосредственно в обработчик вместо фабрики для создания рецептов (или это был бы правильный подход к использованию доменных служб?).

В некотором роде это потеряно если это действительная проблема.

Answer 1

Вообще говоря, ваш рецепт должен заботиться только об уникальном идентификаторе ингредиента, а не о его деталях. Детали ингредиента не требуются для согласованности рецепта.

Я бы предположил, что какое-то действие (например, пользователь, взаимодействующий с пользовательским интерфейсом) добавит ингредиенты в рецепт. Я также предположил бы, что ингредиенты, которые могут быть добавлены, получены из запроса, который возвращает только действительные ингредиенты. Если у вас нет причин беспокоиться о том, что что-то / кто-то собирается подорвать этот процесс, вы, скорее всего, потратите время на решение проблемы, которая вряд ли будет реальной.

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

Ограниченный контекст является концептуальным - он (обычно) не представлен одним классом. Я упоминаю об этом, потому что вы спрашиваете

Нужно ли вводить доменную службу в рецепт B C. , , ?

Вы на самом деле не "вводите" в B C. Опять же, если вам действительно нужна эта проверка, скорее всего, у вас есть класс проверки, который запрашивает ингредиент B C через API или базу данных, чтобы убедиться, что он существует.

рецепт B C подпишется и обновит свои ингредиенты для любых изменений (например, цена / название).

В этом не должно быть необходимости. Рецепт имеет ссылку на каждый из его ингредиентов, поэтому, когда вы запрашиваете рецепт, вы запрашиваете как список ингредиентов, так и детали этих ингредиентов. В зависимости от вашей настройки это может быть SQL соединение или что-то еще (есть много разных способов сделать это в зависимости от вашей настройки). Как правило, следует избегать кэширования сведений об ингредиентах в квитанции B C, если только у вас нет особых опасений относительно производительности. Кэширование всегда добавляет сложности.

Одна из вещей, которые вы обнаружите, продолжая работать с CQRS, - это то, что многие проблемы, которые вы обычно считаете «командными проблемами», на самом деле гораздо легче решить на стороне запроса.

Answer 2

Кажется, что границы БК неверны. Попробуйте найти бизнес-возможности, которые они выполняют для вашего бизнеса. Не отображайте 1: 1 имя объекта с именем ограниченного контекста. Между агрегатами вы не можете гарантировать транснациональную согласованность. Даже если вы проверите свой ингредиент, он может быть там, но через 1 мс он исчезнет, ​​и вы продолжите выполнять свою логику c, думая, что она там. Я не понимаю, почему ингредиент должен быть отдельным B C с рецептом. Какое значение это дает.