Експертні знання про предметну область (Domain Expert Knowledge)

Вступ: Від структури до змісту

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

Але знання про структуру — це лише початок. Тепер нам потрібно зануритися усередину кожного піддомену і зрозуміти:

• Які бізнес-функції він виконує?
• Яка логіка стоїть за цими функціями?
• Як експерти предметної області думають про проблему?
• Яку термінологію вони використовують?

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

Бізнес-задачі (Business Problems)

Перше, що потрібно зрозуміти: програмне забезпечення існує для вирішення бізнес-задач. Але що ми маємо на увазі під "бізнес-задачею"?

Бізнес-задача ≠ Математична задача

Бізнес-задачі можуть включати:

• Оптимізацію робочих процесів
• Мінімізацію ручної праці
• Управління ресурсами
• Підтримку прийняття рішень
• Управління даними
• Автоматизацію повторюваних операцій
• Покращення досвіду клієнтів

Два рівні бізнес-задач

graph TB
A[Бізнес-задачі] --> B[Рівень предметної області]
A --> C[Рівень піддомену]

    B --> D[Глобальна мета компанії]
    C --> E[Конкретна бізнес-компетенція]

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

    D -.Приклад.-> F[FedEx: швидка доставка посилок]
    E -.Приклад.-> G[Оптимізація маршрутів]
    E -.Приклад.-> H[Відстеження посилок]

1. Рівень предметної області (Domain Level)

Це глобальна мета компанії — проблема, яку вона вирішує для своїх клієнтів.

Приклад: FedEx

• Проблема клієнта: Потрібно терміново відправити посилку
• Рішення FedEx: Швидка та надійна доставка по всьому світу
• Цінність: Клієнт може довіритияти, що посилка прибуде вчасно

2. Рівень піддомену (Subdomain Level)

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

Приклади піддоменів FedEx:

Від задачі до рішення

Кожен піддомен має свій цикл "Задача → Рішення":

sequenceDiagram
participant B as Бізнес-задача
participant E as Експерт предметної області
participant D as Розробник
participant S as Програмне рішення

    B->>E: Визначає вимоги
    E->>D: Передає знання
    D->>S: Реалізує функціональність
    S->>B: Вирішує задачу

    B-->>E: Нові вимоги (еволюція)
    E-->>D: Нові знання
    D-->>S: Покращення

Виявлення експертних знань

Тепер, коли ми розуміємо природу бізнес-задач, виникає питання: звідки розробники отримують знання для їх вирішення?

Експерти предметної області (Domain Experts)

Приклади експертів:

• У банку: андеррайтери, трейдери, кредитні аналітики
• У медицині: лікарі, медсестри, фармацевти
• В електронній комерції: мерчандайзери, маркетологи, спеціалісти з логістики
• У страхуванні: актуарії, агенти, оцінювачі ризиків

Розробники ≠ Експерти предметної області

Ментальна модель експерта

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

graph LR
A[Експерт предметної області] -.Має.-> B[Ментальна модель]
B --> C[Концепції]
B --> D[Відносини між концепціями]
B --> E[Правила та обмеження]
B --> F[Бізнес-процеси]

    G[Розробник] -.Вивчає.-> B
    G --> H[Програмна модель]
    H -.Відображає.-> B

    style A fill:#ffe0b2
    style G fill:#bbdefb
    style B fill:#c8e6c9
    style H fill:#fff9c4

Небезпека поверхневого розуміння

Що станеться, якщо розробник не розуміє бізнес-задачу глибоко?

Мудрість Альберто Брандоліні

Альберто Брандоліні (Alberto Brandolini), творець методу Event Storming, висловив глибоку думку:

Успіх програмного проєкту залежить від ефективності обміну знаннями між експертами предметної області та розробниками. Щоб вирішити задачу, потрібно зрозуміти її суть.

Проблеми комунікації

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

Типова структура команди

Майже всі програмні проєкти вимагають співпраці різних ролей:

graph TD
A[Програмний проєкт] --> B[Експерти предметної області]
A --> C[Власники продукту]
A --> D[Розробники]
A --> E[Дизайнери UI/UX]
A --> F[Менеджери проєктів]
A --> G[Тестувальники]
A --> H[Аналітики]
A --> I[Інші спеціалісти]

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

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

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

Традиційний потік знань (антипатерн)

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

Потік знань у традиційній моделі

graph LR
A[Експерт предметної області] -->|Знання| B[Аналітик]
B -->|Вимоги| C[Менеджер проєкту]
C -->|Специфікація| D[Розробник]
D -->|Код| E[Продукт]

    style A fill:#ffcdd2
    style B fill:#fff59d
    style C fill:#80cbc4
    style D fill:#90caf9
    style E fill:#c5e1a5

    A -.Втрата інформації.-> B
    B -.Спотворення.-> C
    C -.Неповнота.-> D

Множинні перекла дання

Знання у традиційному підході піддаються кількатакратному перекладу:

Гра "Зіпсований телефон"

Наслідки поганої комунікації

Що відбувається через множинні перекладання?

Рішення: Пряма комунікація

DDD пропонує більш ефективний спосіб передачі знань від експертів до розробників: використання Єдиної мови (Ubiquitous Language) та пряме спілкування.