Что лучше - поддомен или ограниченный контекст?

Думаю, каждый слышал про домены и ограниченные контексты. Но как эти понятия соотносятся друг с другом? Это одно и тоже или нет? Когда использовать одно, а когда другое? Давайте сломаем стереотипы и развеем мифы!

На самом деле вопрос принципиальный, т.к. на сегодняшний день обе концепции являются доминирующими при проектировании распределённых систем и логическом делении системы на компоненты.

Рассмотрим тему, используя конкретный пример:

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

1. Суть контекста

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

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

В нашем примере можно выделить два поддомена – основной и вспомогательный:

• Игровой движок – распоряжается ресурсами с учётом механики игры.
• Система учёта – регистрирует изменения ресурсов и строит аналитические срезы.

2. Ответственность контекста

Ограниченный контекст задаёт границы:

• Единого языка
• Модели решения
• Физические границы (сервис, модуль, пакет)
• Границы владения (исполнитель, команда)

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

Разные модели одного и того же объекта определяют физические границы и, очевидно, границы владения: у контекста должен быть только один владелец.

Нарушение любой границы приведёт к хаосу и конфликтам.

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

3. Размер контекста

Контекст может охватывать:

• Один поддомен. Часто самый разумный выбор. Модели – раздельные, точные, прагматичные.
• Часть поддомена. Если поддомен большой, его можно разделить на разные контексты, если это способствует эффективному решению разных задач.
• Несколько поддоменов. Небольшие системы или монолиты. Модели – общие, большие, плохо поддерживаемые, провоцирующие конфликты.

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

В нашем примере границы контекстов рационально провести по границам поддоменов. Игровой движок будет в своём контексте, учётная система – в своём. Каждый контекст будет представлен отдельным сервисом.

4. Взаимодействие контекстов

Сопряжение контекстов – это всегда интеграционный слой с определённым контрактом. Тема требует отдельного разбора, но тут важно ответить, на каком языке будет выражен контракт: в терминах модели какого контекста. Выбор всегда зависит от условий решения.

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

Итог

Получается, что поддомены и ограниченные контексты совсем не конкурирующие, а ортогональные концепции. Тем не менее, они очень хорошо дополняют друг друга. Надеюсь, что теперь всё встало на свои места.