Предметно-орієнтоване проєктування

Предметно-орієнтоване проєктування (рідше проблемно-орієнтоване, англ. domain-driven design, DDD) — це підхід до моделювання складного об'єктно-орієнтованого програмного забезпечення. Переваги DDD полягають в наступному:

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

Термін був вперше запроваджений Еріком Евансом в своїй книзі з однойменною назвою.[1]

Основні визначення

  • Домен: Предметна область, середовище, галузь. Предметна область, яку програміст використовує при створенні програмного забезпечення.
  • Модель: Система абстракцій, яка описує окремі аспекти предметної області.
  • Загальна мова: Мова побудована навколо моделі предметної області. Використовується як програмістами при написанні програмного забезпечення, так і іншими членами команди (експертами обраної галузі).
  • Контекст: Середовище, в якому предмет або дія означує своє значення.

Необхідні умови для успішного застосування DDD

  • Обрана галузь не повинна бути тривіальною
  • Команда проєкту повинна розуміти об'єктно-орієнтоване програмування / дизайн
  • Команді проєкту необхідно спілкуватися з експертами у обраній галузі (орієнтуватися в ній)
  • Використання ітеративного процесу розробки програми

Концепція

Патерни в Domain Driven Design та відносини між ними

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

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

Обмежений контекст

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

Тому: Треба точно визначити контекст, в якому використовується модель. Визначити межі використання даної моделі та її характеристики.

Безперервна інтеграція

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

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

Карта контекстів

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

Тому: На етапі проєктування точно позначте, що саме виконує кожна модель і як вона взаємопов'язана з іншими моделями. У кінцевому результаті у вас повинна вийти мапа взаємозв'язків між моделями.

Будівельні блоки DDD

У книзі Domain-Driven Design,[1], сформульований ряд концепцій і практик. Так, наприклад, особлива увага приділяється значенню загальної мови. При проєктуванні моделі предметної області необхідно сформувати спільну мову предметної області для опису вимог до системи, яка працює однаково добре як для бізнес-користувачів або спонсорів, так і для розробників програмного забезпечення. Ця мова означується експертами в обраній галузі. Книга зосереджена на описі доменного шару, як одного із загальних шарів в об'єктно-орієнтованій системі з багатошаровою архітектурою. У DDD є засоби для висловлення, створення та вилучення моделей предметної області:

  • Сутність: Категорія індивідуальних об'єктів, які залишаються незмінними на різних етапах програми, для яких атрибути не грають великого значення, а послідовність та ідентичність, які поширюється в житті усієї системи називаються сутностями.

Приклад: Більшість авіакомпаній відрізняють кожне посадкове місце унікально на кожному польоті. Кожне сидіння є entity в цьому контексті. Тим не менш, Southwest Airlines (або EasyJet / RyanAir для європейців) не робить різниці між кожним місцем, всі місця однакові. У цьому контексті місце насправді Value Object.

Приклад: Коли українці обмінюються гривнями, вони зазвичай не розрізняють унікальність купюр, вони стурбовані номінальною вартістю банкноти. У цьому контексті, гривня є об'єктом значення (Value object). Проте, НБУ може бути стурбована кожною унікальною гривнею, в цьому контексті — кожна гривня буде сутністю (Entity).

  • Сукупність: Колекція об'єктів, які пов'язані між собою завдяки головній сутності (Root Entity), інакше відомій як Aggregate root. Коренева сутність колекції об'єктів гарантує узгодженість змін, що вносяться до сукупності, забороняючи зовнішнім об'єктам посилатися на членів колекції.
  • Сервіс: Коли будь-яка операція концептуально не відноситься до будь-якого об'єкту, вона може бути реалізована в сервісі.
  • Сховище: Отримання об'єктів предметної області повинно делегуватися в спеціалізовані сховища об'єктів. Це дає можливість підміняти місце збереження об'єктів.
  • Фабрика: Створення об'єктів предметної області повинно бути делеговане до спеціалізованих фабрик. Це дає можливість підміняти реалізацію створення об'єктів.

Зв'язок з іншими ідеями

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

Примітки

  1. ↑ а б Evans, Eric (2004), Domain-Driven Design — Tackling Complexity in the Heart of Software, Addison-Wesley.

Посилання