Domain driven design

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
DDD.png

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 .

Зовнішні посилання[ред.ред. код]