2. Обмежені контексти. Інтеграція обмежених контекстів

Що таке обмежений контекст?

Ця проблема в предметно-орієнтованому проєктуванні вирішується доволі просто: необхідно розділити єдину мову на кілька менших за обсягом мов і призначити кожній із них чіткий контекст застосування — її обмежений контекст.

У шаблоні обмеженого контексту самі контексти моделюються як явна і невід'ємна частина предметної області.

Межі моделі

Розглянемо приклад із картами. Кожна карта має свій контекст: авіаційний, морський, ландшафтний, метро тощо. Карта є корисною та несуперечливою лише в рамках свого призначення.

!IMPORTANT Так само, як карта метро є марною для морської навігації, єдина мова в одному обмеженому контексті може бути недоречною в іншому контексті.

Обмежені контексти визначають сферу застосування єдиної мови та моделі, яку вона представляє. Вони дозволяють створювати різні моделі для різних областей задач (problem domain).

Уточнення терміна «єдина мова»

Обмежені контексти дозволяють завершити визначення терміна «єдина мова» (ubiquitous language).

• Єдина мова не є «універсальною». Вона не обов'язково має використовуватися в усій організації.
• Єдина мова застосовується лише в межах свого обмеженого контексту.
• Мова орієнтована на опис лише тієї моделі, яка визначена в межах цього контексту.

Область застосування обмеженого контексту

Розмежування контекстів у предметній області

На прикладі, наведеному на початку, ми побачили, як визначити межі, властиві предметній області. Експерти предметної області часто використовують різні ментальні моделі одного і того ж бізнес-об’єкта.

Щоб створити зрозумілу модель, доводиться:

• Розділити модель на кілька частин.
• Визначити чіткий контекст застосування для кожної частини – тобто обмежений контекст.

Розмір обмеженого контексту

Вплив на дизайн:

• Великі контексти забезпечують узгодженість, але складні у підтримці.
• Маленькі контексти легші в управлінні, але викликають значні витрати на інтеграцію.

!NOTE Наприклад: у великих компаніях із розподіленими командами часто вигідніше ділити контексти для незалежного розвитку різних функцій.

Коли слід розділяти обмежені контексти?

Як уникнути проблем із декомпозицією?

Деколи надмірне розділення функціональності на контексти призводить до:

• Ускладнення синхронізації між контекстами.
• Підвищення витрат на інтеграцію.

Порівняння обмежених контекстів і піддоменів

Піддомени Піддомени виділяються на етапі аналізу бізнесу з метою зрозуміти бізнес-стратегію компанії. Згідно з методологією предметно-орієнтованого проєктування, піддомени класифікуються на:

• Основні (Core)
• Універсальні (Generic)
• Допоміжні (Supporting)

Піддомени схожі на набір взаємопов’язаних сценаріїв використання (use cases), які визначаються предметною областю та вимогами бізнесу. Визначення піддоменів — це виключно бізнес-рішення, і розробники лише аналізують їх для кращого розуміння системи.

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

Взаємодія піддоменів і обмежених контекстів

Теоретично можливо створити одну модель, яка охоплює всю предметну область, але це практично непридатно для складних систем. Коли з’являються конфліктуючі моделі, предметну область доцільно розділити на обмежені контексти.

Якщо моделі все ще занадто складні, їх можна розділити ще більше, утворюючи для кожного піддомену окремий обмежений контекст. Наприклад:

• Маленька система — одна модель охоплює весь домен.
• Складніша система — декілька моделей у межах піддоменів.
• Велика система — кожен піддомен має окремий обмежений контекст.

Границя як концепт проєктування

Границя — ключова концепція системного проєктування.

Фізичні границі Обмежені контексти не лише розділяють моделі, а й визначають фізичні межі реалізації систем.

• Кожен обмежений контекст реалізується як окремий сервіс або проєкт.
• Різні контексти можуть використовувати різні технологічні стеки для задоволення специфічних вимог.
• Один обмежений контекст може містити кілька піддоменів, які логічно розділяються за допомогою просторів імен, модулів чи пакетів.

Границя володіння

Розподіл роботи між командами — це ще одне стратегічне рішення, що використовує концепт обмежених контекстів.

• Один обмежений контекст має належати тільки одній команді.
• Команда може володіти кількома обмеженими контекстами, але жоден контекст не може бути спільним між різними командами.

Обмежені контексти у реальному житті

Під час одного з моїх занять з предметно-орієнтованого проєктування один із учасників зауважив: «Ви сказали, що DDD — це приведення дизайну програмного продукту у відповідність із предметними областями. Але де можна побачити обмежені контексти у реальному житті? В предметних областях немає обмежених контекстів».

Обмежені контексти дійсно не так очевидні, як предметні області і піддомени, але вони існують, так само як і ментальні моделі експертів предметної області. Вам потрібно просто зрозуміти, як експерти предметної області мислять про різні бізнес-сутності та процеси.

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

Семантичні області

Досить своєрідним прикладом різних семантичних областей є значення слова «помідор».

Згідно з визначенням, яке використовується в ботаніці, фрукт є способом поширення рослинами своїх насіння. Фрукт має виростати з квітки рослини та містити хоча б одне насіння. З іншого боку, овоч є загальним терміном, що охоплює всі інші їстівні частини рослини: корені, стебла та листя. Виходячи з цього визначення, помідор — це фрукт.

Але це визначення зовсім не підходить в контексті кулінарного мистецтва. У цьому контексті фрукти та овочі визначаються на основі їх смакових характеристик. Фрукти мають м'яку структуру, бувають солодкими або кислими, їх можна їсти сирими, а овочі мають більш жорстку структуру, менш виражений смак і часто потребують приготування. Згідно з цим визначенням, помідор є овочем.

Отже, в обмеженому контексті ботаніки помідор — це фрукт, а в обмеженому контексті кулінарії — овоч. Але це ще не все. У 1883 році США запровадили 10-відсотковий податок, який поширювався на імпортовані овочі, але не на фрукти. Ботанічне визначення помідора як фрукта дозволяло ввозити помідори до США без сплати податку на імпорт. Щоб закрити лазівку, у 1893 році Верховний суд США ухвалив рішення класифікувати помідори як овочі. Отже, в обмеженому контексті оподаткування помідор є овочем.

Більше того, як говорить мій друг Роме Моура (Romeu Moura), в обмеженому контексті театрального виступу помідор є механізм глядацького відгуку.

Наука

Іншими словами, жодна наукова теорія не буде правильною абсолютно у всіх випадках. Різні теорії корисні в різних контекстах. Цю ідею можна продемонструвати за допомогою різних моделей гравітації, представлених сером Ісааком Ньютоном та Альбертом Ейнштейном. Згідно з законами руху Ньютона, простір і час абсолютні. Вони є сценою, на якій відбувається рух об'єктів. В теорії відносності Ейнштейна простір і час вже не абсолютні, а різні для різних спостерігачів.

Незважаючи на те, що ці дві моделі можна розглядати як взаємовиключні, обидві вони корисні в своїх відповідних (обмежених) контекстах.

Покупка холодильника

Розглянемо більш реалістичний приклад з обмеженими контекстами. Що ви бачите на малюнку? Це просто шматок картону? Ні, це модель. І це модель холодильника Siemens KG86NAI3L.

При ближчому розгляді можна сказати, що цей шматок картону зовсім не схожий на зазначений холодильник. У нього немає дверцят, і навіть колір інший. Однак, це не має значення. Як уже зазначалося, модель не повинна точно копіювати реальний об'єкт. Її мета — допомогти вирішити конкретну задачу.

У нашій квартирі нестандартний вхід на кухню. Картон вирізали точно за розмірами ширини і глибини холодильника. І задача, яку ми вирішуємо за допомогою цієї моделі, — чи зможе холодильник пройти через двері кухні (див. мал).

Нехай картон і не схожий на холодильник, але він виявився дуже корисним, коли потрібно було вирішити, чи варто купувати цю модель або обрати меншу. Знову ж таки, не всі моделі точні, але деякі з них можуть бути корисними. Створення 3D-моделі холодильника, безумовно, буде цікавою ідеєю. Але чи вирішить це проблему ефективніше за картон? Ні. Якщо картон підходить, підходить і 3D-модель, і навпаки.

А як щодо висоти холодильника? Що робити, якщо підставка підходить, але холодильник може бути вищим за дверний проєм? Чи виправдовує це створення 3D-моделі холодильника? Ні. Проблему можна вирішити значно швидше і простіше, якщо виміряти висоту дверного проєму звичайною рулеткою. І що таке рулетка в цьому випадку? Це ще одна проста модель.

Отже, ми маємо дві моделі одного і того ж холодильника. Використання двох моделей, кожна з яких оптимізована для вирішення конкретної задачі, відображає підхід DDD (Domain-Driven Design) до моделювання предметних областей. Кожна модель має свій чітко визначений контекст: картон підтверджує, що підстава холодильника пройде через двері, а рулетка підтверджує, що холодильник не надто високий. Модель повинна виключати зайву інформацію, яка не стосується поставленої задачі. Крім того, немає потреби створювати складну універсальну модель, якщо кілька простіших моделей здатні ефективно вирішити кожну задачу окремо.

Через кілька днів після публікації цієї історії в Twitter я отримав коментар, що замість того, щоб морочитися з картоном, я міг би просто скористатися мобільним телефоном зі сканером LiDAR і додатком доповненої реальності (AR). Давайте проаналізуємо цю пропозицію з точки зору предметно-орієнтованого проектування.

Автор коментаря стверджує, що ця задача вже вирішена іншими людьми і це рішення доступне в відкритому доступі. Не важко зрозуміти, що і технологія сканування, і додаток доповненої реальності — це складні рішення. На жаргоні DDD це відносить задачу перевірки можливості проходу холодильника через двері до універсального піддомену.

Висновок

При кожному зіткненні з неминучим конфліктом ментальних моделей експертів предметної області нам доводиться розбивати єдину мову на кілька обмежених контекстів. Єдина мова в рамках свого обмеженого контексту повинна бути непротирічливою.

Однак у межах обмежених контекстів одні й ті ж поняття можуть мати різні значення.

При виявленні піддоменів розробляються обмежені контексти. Розподіл предметної області на обмежені контексти є стратегічним проектним рішенням.

Обмежений контекст і його єдина мова можуть реалізовуватися та підтримуватися однією командою. Жодні дві команди не повинні одночасно працювати над одним і тим же обмеженим контекстом. Проте одна й та ж команда може працювати з кількома обмеженими контекстами.

Обмежені контексти розбивають систему на фізичні компоненти — сервіси, підсистеми тощо. Життєвий цикл кожного обмеженого контексту відокремлений від усіх інших. Кожен обмежений контекст може розвиватися незалежно від решти системи. Але для формування системи обмежені контексти повинні працювати разом. Деякі зміни непередбачувано можуть впливати і на інші обмежені контексти. В наступному розділі будуть розглянуті різні паттерни інтеграції обмежених контекстів, якими можна буде скористатися для їх захисту від каскадних змін.

Інтеграція обмежених контекстів

Вступ

Обмежений контекст (Bounded Context) — це ключова концепція предметно-орієнтованого проектування (DDD). Вона забезпечує узгодженість єдиної мови (Ubiquitous Language) в межах визначених кордонів та відкриває можливості для побудови моделей. Визначення меж моделі є критично важливим для успішного проектування, адже без чітких меж неможливо побудувати ефективну модель.

Межа відповідальності мов означає, що одна й та сама бізнес-сутність може мати різні призначення в різних обмежених контекстах. Наприклад, "Користувач" у контексті продажу може означати покупця, а у контексті логістики — отримувача товару.

Попри те, що розвиток моделей в обмежених контекстах може бути незалежним, самі контексти не є ізольованими. Вони повинні взаємодіяти для досягнення основних цілей системи, що створює необхідність у визначенні контрактів між ними.

Інтеграція обмежених контекстів

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

Інтеграція обмежених контекстів потребує використання патернів DDD. Вибір патерну залежить від характеру співпраці між командами, які працюють над контекстами. Ми розглянемо три основні типи взаємодії:

1. Співпраця (Cooperation)
2. Споживач-постачальник (Customer-Supplier)
3. Різні шляхи (Separate Ways)

Співпраця (Cooperation)

Патерни співпраці застосовуються до обмежених контекстів, реалізованих командами з добре налагодженою взаємодією. У найпростішому випадку це контексти, що реалізуються однією командою. В інших випадках це можуть бути команди, чия успішність залежить одна від одної. Головним критерієм є щільність спілкування та спільна робота.

До патернів співпраці належать:

1. Партнерство (Partnership)
2. Спільне ядро (Shared Kernel)

Розглянемо детальніше патерн партнерства.

Партнерство (Partnership)

Партнерство — це модель інтеграції, де обмежені контексти координуються за ситуацією. Наприклад, одна команда може повідомити іншу про зміну API, а друга команда адаптується до змін у дусі співпраці.

Основні характеристики:

• Двостороння координація: жодна команда не нав’язує свою мову чи стандарти для контрактів. Рішення приймаються спільно.
• Спільне вирішення проблем: команди разом долають виклики, що виникають під час інтеграції.
• Висока обов’язковість: успіх інтеграції залежить від дисципліни та частоти синхронізації між командами.
• Безперервна інтеграція: регулярна інтеграція змін допомагає мінімізувати час на зворотний зв’язок.

Переваги:

• Гнучкість у виборі підходів до інтеграції.
• Покращення якості співпраці між командами.
• Зменшення ризику конфліктів завдяки спільним рішенням.

Недоліки:

• Потребує тісної співпраці та частих зустрічей, що може бути проблемою для географічно віддалених команд.
• Висока залежність однієї команди від іншої.

Коли застосовувати:

• Команди працюють у тісній взаємодії.
• Є необхідність швидкого реагування на зміни.
• Успіх одного контексту прямо залежить від іншого.

Приклад використання:

Уявімо дві команди: команда "Продажі" і команда "Логістика". Вони співпрацюють для забезпечення безперебійного обслуговування клієнтів. Якщо команда "Продажі" змінює API для замовлень, вона повідомляє команду "Логістика", щоб вони могли внести відповідні зміни до своїх процесів. Разом вони вирішують, як адаптувати інтеграцію, уникаючи конфліктів та простоїв.

Спільне ядро (Shared Kernel)

Незважаючи на те, що межі моделі визначаються обмеженими контекстами, бувають випадки, коли одна й та сама модель піддомена (subdomain) або частина цієї моделі буде реалізована одразу в кількох обмежених контекстах. Тут вкрай важливо зазначити, що загальна модель розробляється відповідно до потреб усіх обмежених контекстів. Ба більше, загальна модель має бути узгодженою в усіх обмежених контекстах, які її використовують.

Наприклад, розглянемо корпоративну систему, що використовує власну модель управління доступами, які надаються користувачам для певних дій. Дозволи, видані кожному користувачеві, можуть надаватися безпосередньо або бути успадкованими від одного з організаційних підрозділів, до яких цей користувач належить. Ба більше, кожен обмежений контекст може змінювати модель авторизації, і зміни в одному контексті мають впливати на всі інші контексти, що використовують цю модель.

Загальні рамки (Shared Scope)

Модель із перекриттям, що використовується в кількох обмежених контекстах, пов'язує життєві цикли. Зміна в загальній моделі одразу впливає на всі обмежені контексти. Щоб мінімізувати каскадні ефекти змін, модель із перекриттям повинна розкривати лише ту частину, яка має бути реалізована в обох контекстах.

В ідеалі спільне ядро (shared kernel) складатиметься з:

• Інтеграційних контрактів.
• Структур даних для передавання даних між обмеженими контекстами.

Реалізація

Спільне ядро (shared kernel) реалізується так, щоб будь-яка модифікація його вихідного коду одразу відображалася у всіх обмежених контекстах, які його використовують.

Способи реалізації:

1. Монорепозиторій: спільне ядро у вигляді одних і тих самих вихідних файлів, на які посилаються кілька обмежених контекстів.
2. Окремий проєкт: спільне ядро виділяється в окремий проєкт і підключається як пов'язана бібліотека.

У будь-якому випадку:

• Кожна зміна в загальному ядрі має запускати інтеграційні тести для всіх обмежених контекстів.
• Зміни слід інтегрувати безперервно, щоб уникнути невідповідностей і розсинхронізації.

Коли слід використовувати спільне ядро

Основний критерій:

Порівняння затратності дублювання та координації.

Через сильну залежність між обмеженими контекстами патерн слід використовувати, якщо витрати на дублювання вищі за витрати на координацію. Це актуально для піддоменів, схильних до частих змін (основні піддомени).

Обмеження використання:

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

Типові випадки використання:

1. Проблеми зі спілкуванням або спільною роботою: наприклад, через географічні або організаційні обмеження.
2. Модернізація застарілої системи: спільна кодова база може слугувати проміжним рішенням для поступового розбиття системи на обмежені контексти.
3. Інтеграція в межах однієї команди: використовується для визначення інтеграційних контрактів і збереження меж обмежених контекстів.

Як уникнути проблем:

• Мінімізувати область дії спільного ядра.
• Запускати інтеграційні тести для кожної зміни.
• Забезпечити ретельну координацію між командами.

Споживач-Постачальник (Customer-supplier)

Загальний опис

Патерни типу "споживач-постачальник" (customer-supplier) описують відносини між двома обмеженими контекстами. Один контекст, постачальник (supplier), надає послуги своєму споживачеві (customer). Постачальник знаходиться "вище за течією", а споживач - "нижче за течією".

Особливості:

• Обидві команди можуть досягти успіху незалежно одна від одної.
• Інтеграційний контракт може диктувати як постачальник, так і споживач.

Основні патерни:

1. Конформіст (Conformist)

Ситуація:

• Баланс сил зміщений на користь постачальника.
• Постачальник надає інтеграційний контракт за принципом "хочеш приймай, хочеш не приймай".

Характеристики:

• Споживач приймає модель постачальника.
• Знижується автономність команди споживача.
• Може бути вигідним, якщо контракт постачальника є стандартним або відповідає потребам.

2. Запобіжний шар (Anticorruption Layer)

Ситуація:

• Баланс сил також на користь постачальника.
• Споживач не бажає підлаштовуватися під модель постачальника.

Рішення:

• Використання запобіжного шару, який перетворює модель постачальника на модель, зручну для споживача.

Використання:

• Для захисту моделі споживача від сторонніх концепцій.
• Коли модель постачальника неефективна, змінюється часто або не відповідає потребам.

3. Сервіс із відкритим протоколом (Open-Host Service)

Ситуація:

• Головна роль належить споживачам.
• Постачальник намагається максимально задовольнити потреби споживачів.

Рішення:

• Постачальник відокремлює модель реалізації від загальнодоступного інтерфейсу.
• Використовується опублікована мова (published language) для зручності інтеграції.

Переваги:

• Дозволяє постачальнику розвивати свою модель без впливу на споживачів.
• Підтримка кількох версій опублікованої мови.

Різні шляхи (Separate Ways)

Ситуація:

Відмова від будь-якої співпраці між контекстами через:

• Труднощі спілкування.
• Відмінності в моделях.
• Особливості дубльованого піддомену.

Причини:

1. Проблеми спілкування: великі розміри організації або внутрішня політика.
2. Універсальний піддомен: дублювання функціональності може бути рентабельнішим, ніж інтеграція.
3. Відмінності в моделях: конформістські відносини або запобіжний шар недоцільні.

Проблеми спілкування

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

Універсальний піддомен (Generic Subdomain)

Причиною розбіжності шляхів команд можуть бути особливості дубльованого піддомену. У тих випадках, коли розглянутий піддомен є універсальним (generic ), а універсальне рішення легко піддається інтеграції, може виявитися, що його локальна інтеграція в кожному обмеженому контексті буде більш рентабельною. Як приклад можна навести фреймворк логування. Навряд чи було б розумно виставляти його як сервіс в одному з обмежених контекстів. Додаткові складнощі інтеграції такого рішення перевагою відмови від дублювання функцій у різних контекстах, яке є обійшлося б дешевше за співпрацю.

Відмінності в моделях

Причиною вибору різних шляхів також можуть стати відмінності в моделях обмеженого контексту. Моделі можуть бути настільки різними, що конформістські відносини стають неможливими, а реалізація запобіжного рівня (anticorruption layer) обійдеться дорожче, ніж дублювання функціональності. У цьому випадку для команд знову-таки вигідніше буде піти різними шляхами. Під час інтеграції основних піддоменів (сore subdomains) від використання різних шляхів краще відмовитися. Дублювання реалізації таких підобластей суперечило б стратегії компанії щодо їхньої найефективнішої та найоптимізованішої реалізації.

Карта контекстів (Context Map)

Призначення:

• Візуалізація обмежених контекстів системи та їхньої інтеграції.

Обмеження

Важливо зазначити, що складання контекстної карти може бути непростим завданням. Коли обмежений контекст системи охоплює кілька піддоменів, можуть бути задіяні кілька інтеграційних моделей. Наприклад, на рис. 4.9 можна побачити два обмежені контексти з двома інтеграційними моделями:

• Партнерство (partnership)
• Запобіжний шар (anticorruption layer)

Ба більше, навіть якщо обмежені контексти не виходять за межі одного піддомену, однаково може бути задіяно одразу кілька патернів інтеграції. Наприклад, якщо модулі піддоменів вимагають різних стратегій інтеграції.

Висновок

Обмежені контексти завжди взаємодіють один з одним, і способи їхньої інтеграції визначаються різними патернами:

• Партнерство (Partnership) — інтеграція відбувається залежно від ситуації.
• Спільне ядро (Shared Kernel) — обмежені контексти використовують спільну модель, що належить усім учасникам.
• Конформіст (Conformist) — клієнт адаптується під модель постачальника.
• Запобіжний шар (Anticorruption Layer) — модель постачальника трансформується відповідно до потреб споживача.
• Сервіс із відкритим протоколом (Open-host Service) — постачальник надає загальнодоступну модель, оптимізовану для клієнтів.
• Різні шляхи (Separate Ways) — дублювання функціональності замість інтеграції.

Контекстна карта є важливим інструментом для відображення інтеграційних підходів, допомагаючи зрозуміти структуру системи, комунікації між компонентами та організаційні аспекти.

Після аналізу та моделювання бізнес-областей у цій главі, далі буде розглянуто тактичні підходи до реалізації логіки предметної області, архітектури системи та координації взаємодії компонентів.

Вправи

1. Який патерн інтеграції в жодному разі не слід використовувати для основного піддомену (core subdomain)? А) Спільне ядро (shared kemel). Б) Сервіс із відкритим протоколом (open-host service). В) Запобіжний шар (anticorruption layer). Г) Різні шляхи (separate ways)
2. Якому нижчому підцомену, найімовірніше, підійде реалізація запобіжного шару (anticorruption layer)? А) Основному підцомену (core subdomain). Б) Допоміжному підцомену (supporting subdomain). В) Універсальному підцомену (generic subdomain). Г) Вірні варіанти Б і В.
3. Якому вищому підцомену, найімовірніше, підійде реалізація сервісу з відкритим протоколом? А) Основному підцомену (core subdomain). Б) Допоміжному підцомену (supporting subdomain). В) Універсальному підцомену (generic subdomain). Г) Вірні варіанти А і Б.
4. Який патерн інтеграції в якомусь сенсі порушує межі володіння обмеженими контекстами? А) Партнерство (partnership). Б) Спільне ядро (shared kemel). В) Різні шляхи (separate ways). Г) Жоден патерн інтеграції не повинен порушувати межі володіння обмеженими контекстами.