Розробка програмного забезпечення, що відповідає потребам та очікуванням бізнесу і користувачів у динамічному й мінливому світі технологій, може бути непростою. Компанії-розробники ПЗ поступово потребують дієвого способу для підвищення прозорості зв’язку між бізнесом і командою розробників. Предметно-орієнтоване проєктування (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. Ми в хорошій компанії, чи не так?
Так, ми застосовуємо DDD як один із основних підходів до розробки комплексного програмного забезпечення для бізнесу. І, здається, ми одна з небагатьох компаній, що працюють з ним.
На порталі DEV спільноти хтось створив дискусію з питанням: «Як знайти компанії, що дотримуються предметно-орієнтованого підходу до проєктування?»
Щоб знайти DDD практиків, йдіть слідами чітко структурованих діалогів… або просто шукайте нашу групу!
Але хтось вирішив припустити, що такі компанії можна знайти по згадці про роботу з DDD в пропозиціях. Попит є, але пропозицій не так багато.
Як бачите, невеликі, згуртовані групи відіграють вирішальну роль у складних галузях. Вони можуть швидко накопичувати знання та універсально використовувати мову своєї сфери.
Для компаній, що втілюють DDD, прийняття парадигми групи на дві піци відкриває шлях до продуктивності та інновацій у різних сферах. Зв’язок малих груп з предметно-орієнтованим проєктуванням дуже потужний.
Зокрема, DDD дає змогу:
- Поліпшити зв’язок: універсальна мова дозволяє розробникам та фахівцям бізнесу співпрацювати ефективніше.
- Відповідність бізнесу: дизайн програмного забезпечення безпосередньо відображає реальні бізнес-процеси та цілі.
- Гнучкість: модульна архітектура дозволяє легко модифікувати додатки залежно від потреб.
- Акцент на користувачі: акцент на предметі дозволяє створювати рішення, адаптовані до потреб користувачів.
- Ефективність: тісна співпраця з предметними фахівцями забезпечує продукцію, що вирішує реальні бізнес-завдання.
DDD та малі організації: можливі проблеми
У менших організаціях інтеграція DDD може бути не так поширена, як у більших компаніях. Однак можливість інтеграції залежить від конкретних потреб і пріоритетів. DDD інтеграція може бути корисною, якщо невелика організація має складну предметну галузь або відчуває потребу в ефективному управлінні та моделюванні бізнес-процесів.
Однак будьте готові до перешкод, що можуть виникнути, зокрема:
- Обмежені ресурси. Менші організації можуть мати менше розробників і часу, що ускладнює впровадження нової методології.
- Труднощі в моделюванні предмета. DDD інтеграція вимагає глибокого розуміння предметної галузі та її належного моделювання. Відсутність досвіду з розробки програмного забезпечення може стати перешкодою.
- Опір змінам. Менші організації можуть активніше опиратися змінам, особливо якщо наявні процеси та архітектура програмного забезпечення вже усталені.
- Технічні обмеження. Застаріла технічна інфраструктура, що не підтримує повну інтеграцію DDD.
Звісно, не всі перешкоди є актуальними для малих організацій. Кожна організація має унікальні характеристики та проблеми, що можуть вплинути на DDD інтеграцію.
Впровадження DDD: поступовий старт
Тепер розгляньмо основні етапи ефективного впровадження DDD, щоб не заплутатися в тонкощах.
Починайте помалу
Починайте роботу з DDD помалу, особливо якщо ви новачок або маєте справу з великою системою. Візьміть невелику, некритичну частину додатка і почніть застосування DDD.
Постійне навчання
Перша реалізація часто буває не ідеальною. Це безперервний процес навчання. Не розчаровуйтесь через перші труднощі. Усвідомте помилки та вчіться на них.
Співпраця
DDD — це не лише програмісти. У ньому задіяна вся група: розробники, менеджери проєктів, системні аналітики, предметні фахівці тощо. Це вимагає тісної співпраці для обміну знаннями та розробки програмного забезпечення на основі вимог бізнесу.
Нарешті, як сказано вище, слід пам’ятати, що DDD не завжди є рішенням для всіх проєктів. Його складність може бути непотрібною для простих додатків, тому важливо оцінити, наскільки він потрібен у проєкті.
Взаємодія: зв’язок DDD з Agile
Отже, як проявляється взаємодія DDD та Agile? DDD та Agile мають схожі принципи, що створює підґрунтя для їхньої успішної інтеграції.
- Активне залучення зацікавлених сторін. У DDD це відображається у повсюдному використанні мови, що сприяє ефективній комунікації, тоді як Agile фокусується на співпраці для створення цінностей.
- Гнучкість та адаптивність. Обидві методології є адаптивними. Agile розроблений для прийняття та реалізації змін, а моделі DDD еволюціонують, щоб відображати розуміння предмета.
- Ітеративна розробка. Agile фокусується на розробці програмного забезпечення невеликими, поступовими кроками. У DDD моделі уточнюються у міру розвитку, що повертає нас до ітеративної природи DDD в Agile.
Зв’язок між DDD та Agile проявляється як взаємодоповнювані відносини. Таким чином, використання DDD в середовищі Agile може впорядкувати комунікацію, забезпечити кращу відповідність бізнес-вимогам і надати високоякісне програмне забезпечення.
Можна з упевненістю сказати, що галузі, які суттєво покладаються на знання предмета, знаходять особливу цінність в акценті DDD на вивченні тонкощів конкретних предметів. Зрештою, суть предметно-орієнтованого проєктування полягає в здатності створювати якісне програмне забезпечення, що тісно пов’язано з потребами бізнесу та його клієнтів.
Для WebLab Technology DDD підхід є невід'ємною частиною нашої ідеології з побудови довгострокового технічного партнерства з клієнтами. Він узгоджується із законом Конвея, який стверджує, що програмні системи відображають комунікаційні структури організацій, які їх створюють.
Наші спеціалізовані групи створюють архітектури, що природно вписуються у предмети наших клієнтів, а глибоке залучення предметних фахівців дозволяє нам створити налагоджений зв’язок, у якому залучені всі. Можливо, що більше компаній усвідомлять потребу в такому підході, то більше цінних переваг DDD буде виявлено в майбутньому.
Зрештою, як писав Ерік Еванс у своїй книзі: «для ефективної комунікації, код має базуватися на тій же мові, на якій написані вимоги — на тій же мові, якою розробники спілкуються один з одним та з предметними фахівцями».