Як осмислити складність предметної області (Managing Domain Complexity)

Вступ: Від мови до меж

У попередній главі ми вивчили Єдинумову (Ubiquitous Language) — спільну мову для опису предметної області. Але щоб Єдина мова була справді ефективною, потрібно визначити, де саме вона діє.

Уявіть, що ви плануєте подорож:

• Для руху по місту вам потрібна карта метро
• Для автомобільної поїздки — дорожня карта
• Для морської навігації — навігаційна карта
• Для польоту — аеронавігаційна карта

Що ми вивчимо?

У цій главі ми дослідимо:

Що таке модель?

Перш ніж говорити про Обмежені контексти, потрібно зрозуміти, що таке модель.

Моделі в реальному світі

Розглянемо приклади моделей з різних сфер:

Ключові властивості моделі

graph TD
    A[Модель НАДА має] --> B[Конкретну мету]
    A --> C[Межі застосування]
    A --> D[Спрощення реальності]

    B --> E[Вирішення конкретної задачі]
    C --> F[Контекст, де модель корисна]
    D --> G[Фокус на важливому]

    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#c8e6c9
    style D fill:#ffcdd2

Моделі в програмуванні

У контексті програмного забезпечення модель предметної області — це структурований спосіб представлення бізнес-концепцій, правил та процесів.

Приклад: Модель "Замовлення" в електронній комерції

// Модель Замовлення
public class Order {
    public OrderId Id { get; private set; }
    public CustomerId CustomerId { get; private set; }
    public List<OrderItem> Items { get; private set; }
    public OrderStatus Status { get; private set; }
    public Money TotalAmount { get; private set; }

    public void AddItem(Product product, int quantity) {
        // Бізнес-логіка додавання товару
    }

    public void Confirm() {
        // Бізнес-логіка підтвердження
    }
}

Ця модель:

• Включає: ID, товари, статус, загальну суму, операції (додати товар, підтвердити)
• Ігнорує: Деталі доставки (це інша модель), історію змін статусу, технічні деталі зберігання

Обмежені контексти (Bounded Contexts)

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

Чому потрібні обмежені контексти?

Розглянемо приклад, який ілюструє проблему:

Рішення: Розділити на Обмежені контексти

Замість однієї складної моделі створюємо три Обмежені контексти:

graph LR
    A[Авіакомпанія] --> B[Контекст Продажів]
    A --> C[Контекст Операцій]
    A --> D[Контекст Фінансів]

    B --> E[SalesTicket]
    C --> F[FlightTicket]
    D --> G[FinancialTransaction]

    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#c8e6c9
    style D fill:#ffcdd2

    E -.Ціна, Знижки.-> E
    F -.Місце, Багаж.-> F
    G -.Оплата, Податки.-> G

Тепер кожен контекст має свою чітку модель квитка:

• SalesTicket у контексті продажів
• FlightTicket у контексті операцій
• FinancialTransaction у контексті фінансів

Межі узгодженості

Обмежені контексти визначають межі узгодженості Єдиної мови.

graph TB
    subgraph BC1[" Обмежений контекст: Продажі"]
        A1[Customer = Покупець]
        A2[Order = Замовлення]
        A3[Price = Ціна продажу]
    end

    subgraph BC2["Обмежений контекст: Логістика"]
        B1[Customer = Одержувач]
        B2[Shipment = Відвантаження]
        B3[Price = Вартість доставки]
     end

    style BC1 fill:#e3f2fd
    style BC2 fill:#fff3e0

У контексті Продажів "Customer" — це покупець, у контексті Логістики — одержувач посилки. Обидва значення правильні у своїх контекстах!

Уточнення терміна "Єдина мова"

Обмежені контексти дозволяють завершити визначення Єдиної мови.

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

Визначення меж Обмеженого контексту

Як визначити, де має проходити межа Обмеженого контексту?

Відправна точка: Непротиворечність Єдиної мови

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

Стратегічне рішення про розмір

Визначення розміру Обмеженого контексту — це стратегічне проектне рішення.

Причини для поділу на менші контексти

Чому ви можете захотіти розділити великий Обмежений контекст на менші?

Що уникати: Надмірне розділення

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

Тепер розберемо ключову різницю та зв'язок між Піддоменами та Обмеженими контекстами.

Піддомени (Subdomains)

Характеристики піддоменів:

• Визначаються бізнес-стратегією
• Це аналітична концепція
• Ідентифікуються через анал із предметної області
• Існують незалежно від реалізації
• Типи: Core, Generic, Supporting

Обмежені контексти (Bounded Contexts)

Характеристики Обмежених контекстів:

• Визначаються рішеннями проектування
• Це концепція реалізації
• Створюються розробниками та архітекторами
• Можуть змінюватися залежно від потреб
• Межі моделей і Єдиної мови

Порівняльна таблиця

Варіанти відображення

Як співвідносяться піддомени та Обмежені контексти?

Варіант 1: Один контекст на всю предметну Область (антипатерн для великих систем)

Варіант 2: Контексти відповідають непротиворечності моделі

Варіант 3: Один контекст на кожен піддомен

Варіант 4: Кілька контекстів на один піддомен

Ключова фраза для запам'ятовування

Резюме та ключові думки

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

Зв'язок з практикою

Розуміння Обмежених контекстів є фундаментальним для:

• Архітектури мікросервісів: Кожен мікросервіс зазвичай відповідає Обмеженому контексту
• Командної структури: Команди часто організовуються навколо Обмежених контекстів
• Управління складністю: Обмежені контексти дозволяють розбити монолік на керовані частини