Як чітко визначити межі обмеженого контексту

Після місяця чи близько місяця читання та дослідження DDD я вирішив розпочати власний проект і створив DDD із цими обмеженими контекстами>

• Клієнти
• Продукція
• Замовлення
• Рахунки

Кожен обмежений контекст містить API відпочинку як презентаційний шар, доменний рівень, стійкий шар.

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

• коли я хочу створити нового клієнта, видати новий рахунок-фактуру, створити новий порядок, який я хочу, наприклад, список країн для доступу. Чи повинен я:

а) створити перелік країн у кожному БК

б) створити API BC -> і використовувати його для отримання списку доступних країн

в) використовувати сторонній API та витягувати дані через антикорупційний шар у кожному БК

• під час інтеграції з стороннім API за допомогою антикорупційного шару або адаптерного шару, які дані потрібно включити до моєї моделі домену? Наприклад, якщо я хочу інтегрувати API zendesk з клієнтом BC. Чи потрібен мені лише квиток ID у своєму домені, або мені потрібно витягти всі дані із Zendesk, до яких я хочу отримати доступ та використовувати їх у клієнті BC?

Якщо мій додаток MVC насправді отримує дані з API (шари презентації моїх обмежених контекстів), мені дуже важко чітко визначити межі кожного БК. Чи означає це, що правильно розроблений БК обслуговуватиме один контролер MVC, не потребуючи додаткових API?

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

Я також хотів трохи поглянути на вашу модель. Перераховані вами фрагменти можуть бути "суб'єктами" в одному "обмеженому контексті", залежно від структури компанії. БК часто визначаються навколо різних областей / відділів / команд, оскільки це часто природна межа між "всюдисущою мовою". Так, наприклад, замість продажів / товарів / замовлень я очікував, що БК будуть узгоджуватися з напрямками продажів / виробництво / складування.

Всередині цих BC ви не зосереджуєтесь на іменниках. Ви орієнтуєтесь на відмінки вживання та створюєте моделі іменників, які можуть виконувати відмінки вживання. Методи на "сукупному корені" виконують випадки використання та вносять відповідні зміни у відповідні моделі.

... всі моделі помиляються, але деякі корисні.

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

Існують конкретні зразки, створені DDD (наприклад, сховища, специфічні шари тощо), які є засобом для досягнення мети. Але ці схеми не гарантовано є найкращими зразками для кожного випадку, навіть в межах DDD. Так само, як DDD - це не "відповідь" для кожного проекту. Вам просто потрібно зробити те, що пропонує ваш аналіз, - це найпрактичніше.

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

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

Наприклад, у домені клієнта "країна" може бути пов'язана з місцем проживання чи громадянством. Під час виставлення рахунків це може бути пов'язано з обмінними курсами. У деяких із цих доменів вам може знадобитися турбуватися про тарифи тощо.

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

Що має відбуватися у ваших моделях домену, коли країну окупує іноземна держава?

Мати на увазі; багато хто з нас звикли думати про структуру даних; який взаємозв'язок між однією частиною даних та іншою. І це чудово, коли ви розглядаєте звіти та намагаєтесь забезпечити, щоб усі потрібні вам дані були зібрані вашим рішенням. Але доменні моделі стосуються не лише структури, а зміни. Вам також потрібно привернути свою увагу до цієї частини і переконатися, що ви добре розумієте, як дані обмежують зміни (і як ці обмеження змінюються від одного обмеженого контексту до іншого).

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

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

1. Визначте обов'язки системи вищого рівня або бізнес-можливості. Найкращий спосіб зробити це, я думаю, це створити кроки, через які проходить ваше підприємство, щоб отримати ділову цінність. Логічні межі, з якими ви стикаєтесь, - це ваші бізнес-послуги або, якщо вам подобається, обмежений контекст.
2. Поглиблюйтесь глибше в межах кожної послуги.
3. Визначте зв’язок між вашими службами поряд із першими двома пунктами.

Тож початкова увага зосереджена на тому, як працює ваш бізнес.

Пара практичних порад:

1. Якщо одному з ваших контекстів / служб / тощо потрібні дані інших контекстів, швидше за все, ваші межі неправильні.
2. Дуже бажаний спосіб контекстної комунікації на основі подій. Це ключ до масштабованості та надійності. Якщо вам потрібно синхронне спілкування, то, ймовірно, знову ж таки, ви межі неправильні. Крім того, синхронне спілкування вб'є вашу систему.
3. Ваш домен більш стійкий у кінцевому рахунку, ніж ви думаєте. Як і всі інші. Не намагайтеся зробити все на 100% послідовним. Практичного сенсу в цьому немає.
4. Контексти не потрібно оркеструвати. Вони є самостійними. Як люди.

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