Як осмислити складність предметної області (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() {
        // Бізнес-логіка підтвердження
    }
}

::

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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