DDD: один ограниченный контекст или два?

Предположим, я построил систему для своего клиента, которая позволяет игрокам поддерживать портфель ставок и отслеживать их прибыли / убытки с течением времени. Эта система поддерживает много сложной предметной логики - ставки на разные виды спорта, переходы выигрышей на другие ставки и т. Д.

Далее мой клиент хочет поддержать идею типстеров. Советники на самом деле не играют в азартные игры, вместо этого они создают "листы с советами", которые являются их подсказками относительно того, что делать. Листы с подсказками могут быть разных видов - некоторые могут включать в себя советы по любому пари, другие предлагают только советы по скачкам и так далее. Мой клиент хочет, чтобы система отслеживала производительность гонщиков точно так же, как она отслеживает производительность игроков, с дополнительным преимуществом возможности сравнивать производительность внутри и между различными типами подсказок (например, кто является лучшим советником по скачкам? они вообще выступают лучше, чем футболисты?)

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

Итак, мои вопросы:

  1. Это действительно отдельные ограниченные контексты? Я осторожен с добавлением категоризации в контекст игроков (похоже на скользкий уклон).
  2. Если это разные контексты, я должен:
    • Поделиться логикой отслеживания производительности между ними (т.е. делиться DLL, JAR и т. Д.)? Это создает тесную связь реализации между контекстами, которая кажется неправильной.
    • Оставьте логику отслеживания производительности в контексте, ограниченном азартными играми, поместите логику категоризации в контекст ограничителя подсказок и попросите ли контекст контекста отслеживать производительность? В этом случае кажется, что контекст подсказок будет отправлять команды в контекст азартных игр, что опять-таки кажется неправильным (мне удобнее с событиями).
    • Есть ли что-то еще... какой-то слой композиции, который связывает и коррелирует между обоими контекстами?

осветление

Портфель игрока и лист с подсказками типстера практически идентичны - единственное отличие состоит в том, что лист с подсказками можно классифицировать (например, скачки, футбол и т. Д.).

Отслеживание эффективности - это измерение прибыли / убытка портфеля / чаевых.

Источник

4 ответа

Решение

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

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

Источник

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

  2. Синяя книга, Часть 4 (Стратегический дизайн), Глава 15 (Дистилляция), вводит понятие общего субдомена, который хорошо вписывается в ваш сценарий. Расчеты производительности можно рассматривать как общий субдомен, потому что, хотя они важны для общего функционирования вашей модели, они могут быть изолированы в библиотеку, которая может использоваться двумя BC. Это образец для дистилляции вашей модели и устранения технических проблем. Вам не нужно реализовывать сложный обмен сообщениями или RPC-связь между BC, просто используйте общую библиотеку с интерфейсами, раскрывающими намерения.

Источник

Это очевидно случай (по крайней мере) 2 ограниченных контекстов (BC), тот факт, что они имеют другой язык предметной области, является самой большой подсказкой.

Если я правильно предприму, отслеживание производительности является концепцией домена и, вероятно, это должен быть сам BC. Вы можете определить интерфейсы для общего отслеживания и конкретного отслеживания (для подсказок) - в проекте с общим интерфейсом - который будет реализован объектами из других BC. Таким образом, PerformanceTracking BC не будет заботиться о конкретных игроках или подсказках, а другие BC не будут связаны с конкретным трекером производительности.

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

Источник

Я думаю, что это два разных контекста, и вы тоже так думаете, верно?

Я лично использовал бы доменные события из игрового контекста для генерации информации об отслеживании производительности. Код все еще слабо связан (поскольку логика зависит только от событий домена).

Конечно, вы можете создать адаптеры, которые не входят ни в один из этих jar /dll. То есть что-то, что подписывается на события домена в context1, адаптирует информацию и затем вызывает вещи в context2. Таким образом, вы получаете 100% прозрачность между контекстами.

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