Предметно-орієнтоване проєктування (DDD): у чому користь підходу і хто його використовує

Усім привіт! Мене звуть Олександр Книга, я Solution Architect у компанії WebLab Technology.

У цій статті я поділюсь прикладом того, як Domain Driven Design підхід може змінити розробку і привнести виграшну перевагу у сфері створення програмного забезпечення.

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

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

Розробка програмного забезпечення, що відповідає потребам та очікуванням бізнесу та користувачів у динамічному й мінливому світі технологій, може бути непростою. Компанії-розробники ПЗ поступово потребують дієвого способу для підвищення прозорості зв’язку між бізнесом і командою розробників. Предметно-орієнтоване проєктування (DDD) допомагає розв’язати цю проблему, сприяючи розумінню предмета й постійній співпраці між розробниками та фахівцями з бізнесу. Водночас зацікавлені сторони краще розуміють технічні можливості та обмеження.

Наприклад, аналіз 100 проєктів, проведений Standish Group, засвідчив, що причиною 70% доробок був брак знань у предметній галузі на етапах формування вимог та проєктування, і підтвердив, що DDD сприяє взаєморозумінню між бізнесом та розробниками.

За даними Forrester, групи розробників, які практикують ітеративну модель DDD, працюють на 60% швидше, а не витрачають місяці на попередній аналіз.

Дослідження, проведене Кембриджським університетом, показало, що моделювання знань предметної галузі в межах DDD збільшує продуктивність групи на 29%. Зрозуміло, що такий підхід розкриває внутрішні знання з предметної галузі.

Тож навіщо компаніям потрібен цей підхід, хто його використовує і в чому його суть?

Основні принципи предметно-орієнтованого проєктування

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

• Перший принцип — визначення пріоритетів предметної моделі. Вона представляє основні бізнес-суб’єкти, поведінку, відносини та правила. Реалізація коду безпосередньо відображає предметну модель, а не навпаки. Модель розробляється ітеративно, а не визначається заздалегідь.
• Ще один ключовий принцип — розробка універсальної мови. Спільна лексика розробників і бізнес-експертів стандартизує термінологію та знання предметної галузі, усуваючи двозначність і неузгодженість між групами.
• DDD також містить стратегічний і тактичний етапи проєктування. Стратегічне проєктування зосереджено на високорівневій організації предметної галузі у вигляді обмежених контекстів і підобластей. Тактичне проєктування охоплює шаблони та компоненти реалізації нижчого рівня — сутності, сервіси та репозиторії.

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

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

У зв’язку з цим на думку одразу спадають гексагональна архітектура та чиста архітектура, що мають спільну мету — відокремлення завдань. Ви можете ізолювати основну бізнес-логіку від зовнішніх проблем, розділивши застосунки на вільно пов’язані компоненти.

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

Стратегічне проєктування

У контексті DDD стратегічне проєктування є невіддільною частиною розробки програмного забезпечення. Воно містить основні аспекти:

• Огляд. Стратегічне проєктування починається з огляду проблемного предмета та цінності бізнесу. На цьому етапі досліджуються ключові концепції та процеси, визначаються основні бізнес-потреби та цілі.
• Простір проблем і простір рішень. Структура стратегічного проєктування визначає ці два основні концептуальні простори. Простір проблем фокусується на дослідженні та аналізі предмета бізнесу, визначенні сутностей, агрегатів, послуг та взаємозв’язків між ними. Простір рішень стосується створення моделі, яка ефективно розвʼязує проблеми, визначені в проблемному просторі.
• Обмежені контексти. Обмежені контексти — це обмежені підрозділи предмета, що відповідають зонам відповідальності конкретних груп розробників. Кожен контекст визначає свої сутності, агрегати, сервіси та правила. Керування межами контекстів має важливе значення для ізоляції та розуміння різних частин предмета.
• Основний предмет. Основний предмет — це ядро бізнесу, його найважливіша і найцінніша частина. У межах стратегічного проєктування основний предмет критично важливий, оскільки є фокусом розробки та містить фундаментальні абстракції та бізнес-правила, що визначають функціональність програмного забезпечення.

Стратегічне проєктування в контексті DDD дозволяє створювати ефективні стратегії розробки програмного забезпечення, враховуючи особливості предмета бізнесу. Це допомагає розробникам створювати програмне забезпечення, що відповідає бізнес-вимогам, гнучко масштабується та легко обслуговується з часом.

Тактичне проєктування

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

Воно починається з огляду предмета бізнесу та його вимог. На цьому етапі аналізують основні процеси, сутності, агрегати та взаємозв’язки між ними. Мета — отримати глибше розуміння основних компонентів предмета.

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

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

Один з прикладів використання інструментарію тактичного проєктування — створення репозиторіїв. Репозиторії відповідають за зберігання та отримання даних зі сховища певної сутності чи сукупності сутностей. Вони забезпечують єдиний інтерфейс для взаємодії зі сховищем даних та інкапсулюють деталі зберігання даних.

Тактичне проєктування також розрізняє сервіси застосунків і сервіси домену. Служби застосунків координують дії та взаємодію між різними сутностями та агрегатами в них. Що стосується доменних сервісів, то вони зберігають бізнес-логіку і виконують операції, пов’язані лише з предметною моделлю.

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

Роль обмеженого контексту та універсальної мови в DDD

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

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

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

Інша важлива концепція, на якій слід зосередитись, коли йдеться про DDD — це універсальна мова.

Її можна схарактеризувати як спільну мову, яку використовують і розуміють усі учасники групи розробників.

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

Її основна місія — допомога в уникненні непорозумінь, пов’язаних із різним тлумаченням і розумінням термінів чи понять, і, в певному сенсі, сприяння глибшому і точнішому моделюванню предметної галузі.

Ключ до нових рішень: що дає DDD підхід і на кого він розрахований

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

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

Сила малих DDD-груп

Предметно-орієнтоване проєктування добре підходить невеликим, автономним групам. Прикладом є концепція «групи на дві піци». Ідея полягає в тому, що група має бути досить малою, щоб прогодуватися двома піцами. Це забезпечує зосередженість, узгодженість і продуктивність.

Ми бачимо, як підхід «групи на дві піци» переплітається з DDD та успішно застосовується такими лідерами галузі, як Netflix (що дозволило їм швидко масштабувати платформу) та Uber (вони змогли гнучко ізолювати інциденти та керувати коливаннями попиту).

Здається, що DDD — це ексклюзивний клуб, членами якого є Netflix, Uber та наша скромна WebLab Technology. Ми в хорошій компанії, чи не так?

На порталі DEV спільноти хтось створив дискусію з питанням: «Як знайти компанії, що дотримуються предметно-орієнтованого підходу до проєктування?».

Щоб знайти DDD практиків, йдіть слідами чітко структурованих діалогів... або просто шукайте нашу групу!

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

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

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

Зокрема, DDD дає змогу мати:

• Поліпшення зв’язку: універсальна мова дозволяє розробникам і фахівцям бізнесу співпрацювати ефективніше.
• Відповідність бізнесу: дизайн програмного забезпечення безпосередньо відображає реальні бізнес-процеси та цілі.
• Гнучкість: модульна архітектура дозволяє легко модифікувати застосунки залежно від потреб.
• Акцент на користувачі: акцент на предметі дозволяє створювати рішення, адаптовані до потреб користувачів.
• Ефективність: тісна співпраця з предметними фахівцями забезпечує продукцію, що вирішує реальні бізнес-завдання.

DDD та малі організації: можливі проблеми

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

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

• Обмежені ресурси. Менші організації можуть мати менше розробників і часу, що ускладнює впровадження нової методології.
• Труднощі в моделюванні предмета. DDD інтеграція вимагає глибокого розуміння предметної галузі та її належного моделювання. Відсутність досвіду з розробки програмного забезпечення може стати перешкодою.
• Опір змінам. Менші організації можуть активніше опиратися змінам, особливо якщо наявні процеси та архітектура програмного забезпечення вже усталені.
• Технічні обмеження. Застаріла технічна інфраструктура, що не підтримує повну інтеграцію DDD.

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

Впровадження DDD: поступовий старт

Тепер розгляньмо основні етапи ефективного впровадження DDD, щоб не заплутатися в тонкощах.

1. Починайте помалу.

Починайте роботу з DDD помалу, особливо якщо ви новачок або маєте справу з великою системою. Візьміть невелику, некритичну частину застосунка і почніть використання DDD.

2. Постійне навчання.

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

3. Співпраця.

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

Нарешті, як сказано вище, слід пам’ятати, що DDD не завжди є рішенням для всіх проєктів. Його складність може бути непотрібною для простих застосунків, тому важливо оцінити, наскільки він потрібен у проєкті.

Взаємодія: зв’язок DDD з Agile

Отже, як проявляється взаємодія DDD та Agile? DDD та Agile мають схожі принципи, що створює підґрунтя для їхньої успішної інтеграції.

1. Активне залучення зацікавлених сторін. У DDD це відображається у повсюдному використанні мови, що сприяє ефективній комунікації, тоді як Agile фокусується на співпраці для створення цінностей.
2. Гнучкість та адаптивність. Обидві методології є адаптивними. Agile розроблений для прийняття та реалізації змін, а моделі DDD еволюціонують, щоб відображати розуміння предмета.
3. Ітеративна розробка. Agile фокусується на розробці програмного забезпечення невеликими, поступовими кроками. У DDD моделі уточнюються у міру розвитку, що повертає нас до ітеративної природи DDD в Agile.

Зв’язок між DDD та Agile проявляється як взаємодоповнювані стосунки. Так, використання DDD в середовищі Agile може впорядкувати комунікацію, забезпечити кращу відповідність бізнес-вимогам і надати високоякісне програмне забезпечення.

Висновки

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

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

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

Зрештою, як писав Ерік Еванс у своїй книзі Domain-Driven Design: «Для ефективної комунікації код має базуватися на тій же мові, на якій написані вимоги — на тій же мові, якою розробники спілкуються один з одним та з предметними фахівцями».