Методологія Domain Driven Design (іноді називають Domain Driven Development чи Development by Domain Model) була створена Еріком Евансом (Eric Evans) та описана як набір тактик та патернів у книзі Domain Driven Design. Одразу хочу зазначити, що книга Еванса неймовірно нудна і я раджу прочитати іншу книгу, що мені більше сподобалась – Patterns, Principles and Practices of Domain Driven Design. Нижче приведені обкладинки обох.
Мені загалом подобається DDD, але я бачу декілька недоліків у подачі матеріалу та ознаки старого доброго інфобізу (торгівлю водою). У цій публікації я поділюся власним розумінням та критикою DDD.
DDD патерни
Патерни DDD є найбільш конкретною частиною DDD, але при тому мають найменше відношення до моделей тих чи інших предметних областей. Знайомство з патернами корисне, але мені здається, що вони були додані для об’єму та аби DDD не здавася занадто абстрактним. Майже усі патерни, що згадуються у DDD, існували задовго до того, як принципи DDD були сформовані.
Що дійсно DDD’шного?
На це питання важливо відповісти, оскільки, усе, що викладено у Domain Driven Design, існувало і раніше, нехай під іншими назвами. Швидше за все, DDD не приносить нічого нового, а є просто компіляцією деяких практик, які автори DDD, покладаючись на свій досвід, вважають такими, що дозволяють досягти найкращих показників у розробці. Так це чи ні залежить від проєкту та людей.
Я раджу подивитися наступний доповідь аби не переоцінювати DDD та мати більш здорове ставлення до нього:
Що я вважаю найкориснішим у DDD?
Добре, патерни – це не так важливо (~0.9 коеф. шляповості), а що ж тоді важливого у DDD? Одразу хочу зазначити, що те, що я перерахую нижче, не є винаходом Еріка Еванса чи будь-куго ще із DDD спільноти. Все це існувало набагато раніше, але багато хто дізнався про це саме із книжок та доповідей по Domain Driven Design.
- Ubiquitous Language
- Тісна співпраця з експертами у предметній області
- Bounded Context та context mapping
Розглянемо кожен з елементів списку детальніше.
Ubiquitous Language
Ubiquitous Language – це узгоджений з експертами у предметній області словник термінів, які не вигадані розробниками, а узяті із предметної області для створення її моделі (Domain Model).
Такий словник дуже корисний, адже дозволяє розробникам та експертам у предметній області спілкуватися однією мовою та розуміти одне одного. Важливо розуміти, що Ubiquitous Language – це не просто словник, розділ у Confluence чи іншій системі для розробки документації, а підхід. Ubiquitous Language треба практикувати, а не створювати.
Якщо ми звернемося до Agile Manifesto, то побачимо там одразу два правила, які відносяться до Ubiquitous Language, а саме:
- Individuals and interactions over processes and tools
- Customer collaboration over contract negotiation
Agile – це загалом про швидке просування та тісну співпрацю, для якої просто необхідна спільна мова.
Тісна співпраця з експертами у предметній області
Не варто пояснювати чому це важливо, але чомусь я дуже рідко спостерігав ситуацію, коли дійсно була організована тісна співпраця. У багатьох компаніях розробники та експерти у предметній області нехтують спілкуванням одне з одним та використовують антипатерн “зіпсований телефон”, що полягає у створенні окремої позицій відповідальних за збір вимог та взаємодію з замовником, беспосереднім користувачем чи будь-яким іншим stakeholder’ом.
Що цікаво, в багатьох таких компаніях можна почути, що вони працюють за Agile та DDD. Це можна розцінювати лише як дурість, або свідому брехню з метою видати себе за провідну компанію, що реалізує усі модні тренди.
Bounded context та context mapping
Концепція обмежених контекстів виникає скрізь. Визначення меж – це одне з основних завдань філософії та онтології, а у програмуванні так чи інакше цього стосуютсья такі відомі принципи, практики та підходи, як:
- Single Responsibility Principle
- Interface Segregation Principle
- Low Coupling / High Cohesion
- Object Oriented Analysis / Design / Programming
- Service Oriented Architecture
- Microservices architecture
- Modular design
- …
Bounded Context – хороша ідея, але достатньо розмита. В DDD не існує чіткого алгоритму як їх визначати. Багато архітекторів, консультантів та розробників пишуть на цю тему, пропонуючи різні підходи, але універсального підходу не існує. Є лише набір тактик, типу EventStorming, які можуть використовуватися для визначення обмежених контекстів, але оскільки відсутні критерії якості визначених обмежених контекстів, то результати роботи двох команд можуть сильно відрізнятися. Загалом, добре вже те, що є хоч якісь обмежені контексти.
Дивно, що люди говорять про розмиту та зовсім не нову ідею bounded context’ів із таким захопленням і виразом очікування від співбесідника якоїсь реакції на їх згадування. Дещо схоже на якийсь культ. Хоча, це не дивно. Якщо людина схопилася за назву bounded context, то вона дійсно не розуміє загальної ідеї та пов’язаної проблематики.
Вона щось вхопила нове і задоволено побігла трясучи його у руках та вигукуючи його назву. Якщо людина схопилася за термін bounded context, то це значить, що вона ознайомилась із творчістю DDD спільноти, але не знайшла тих же проблем та рішень набагато раніше, до того, як звернула увагу на DDD. Якщо обмежені контексти так сильно вразили людину, то, скоріше за все, вона їх не розуміє, як і розробку взагалі.
Висновки
- Коли хтось говорить, що він працює по DDD – вже зрозуміло, що це не так, що DDD – це культ вантажу і людина дійсно мало розуміється на тому, що робить.
- Коли люди намагаються створити якісь фреймворки для DDD чи Hexagonal/Clean Architecture – вони не розуміють DDD чи Hexagonal/Clean Architecture. Я сам таким займався десь у чотирнадцятому році і єдине до чого прийшов, то це до того, що подібні спроби – шляпа. Фреймворк я створив, але відмовився від його використання, бо усе, що з його допомогою можна було створити – то купа лайна. Я бачив багато подібних спроб. Всі вони були такі ж невдалі, як і моя.
- DDD варте ознайомлення, як і т.з. DDD патерни, але не варто бути безкомпромісним прибічником DDD. Варто навантажувати свою семантичну мережу, шукати однакові патерни в усьому, що тобі трапляється на очі, але не варто піддаватися гіпнозу, необхідно бути над усім, а не у ньому.
- Головне у DDD – це ідея тісної роботи з stakeholder’ами, але для цього не має потреби у DDD.
- Загалом коеф. шляповості у DDD ~0.7. Варте ознайомлення, але не має бути релігією.
Залишити відповідь