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

unix проти windows

Важливі теми для доменно-керованого дизайну (DDD)

• Що таке Domain-Driven Design (DDD)?
• Важливість знань предметної області
• Стратегічний дизайн у доменно-орієнтованому дизайні (DDD)
• Тактичні шаблони проектування в доменно-орієнтованому проектуванні (DDD)
• Переваги доменно-керованого дизайну (DDD)
• Проблеми доменно-орієнтованого проектування (DDD)
• Випадки використання доменно-керованого дизайну (DDD)
• Реальний приклад доменно-керованого дизайну (DDD)

Що таке Domain-Driven Design (DDD)?

Домен

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

Загнаний

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

Дизайн

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

Дизайн, орієнтований на предметну область, — це концепція, введена програмістом Ерік Еванс у 2004 році у своїй книзі Проектування, орієнтоване на предметну область: боротьба зі складністю в серці програмного забезпечення

Важливість знань предметної області

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

Відповідно до Ерік Еванс Коли ми розробляємо програмне забезпечення, ми повинні зосереджуватися не на технологіях, а на бізнесі. Пам'ятайте,

Робота клієнта не полягає в тому, щоб знати, чого він хоче – Стів Джобс

Стратегічний дизайн у доменно-орієнтованому дизайні (DDD)

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

Давайте розглянемо деякі ключові концепції стратегічного проектування в доменно-орієнтованому дизайні (DDD)

1. Обмежені контексти

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

2. Відображення контексту

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

3. Стратегічні моделі

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

4. Спільне ядро

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

5. Антикорупційний рівень (ACL)

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

6. Усюдисуща мова

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

Деякі з ключових принципів Ubiquitous Language:

• Спільне розуміння : Основною метою Ubiquitous Language є встановлення спільного розуміння проблемної області серед усіх членів команди розробників, включаючи розробників, експертів у галузі, бізнес-аналітиків та зацікавлених сторін. Використовуючи спільну мову, усі учасники можуть ефективніше спілкуватися та точно передавати концепції та вимоги домену.
• Послідовність і ясність : Ubiquitous Language сприяє узгодженості та ясності спілкування завдяки використанню точної та недвозначної термінології. Кожен термін або фраза в мові повинна мати чітке та узгоджене значення,
• Узгодження з бізнес-концепціями : Мова, яка використовується в DDD, повинна тісно відповідати термінології та концепціям, що використовуються в бізнес-сфері. Воно має відображати те, як експерти в галузі думають і говорять про проблемну область, гарантуючи, що програмне забезпечення точно представляє концепції та процеси реального світу.
• Еволюційна природа : Ubiquitous Language не є статичною, а розвивається з часом, оскільки команда отримує глибше розуміння домену та змінюються вимоги. Він має адаптуватися, щоб відображати нові ідеї, відкриття або зміни в бізнес-пріоритетах, гарантуючи, що мова залишається актуальною та актуальною протягом усього процесу розробки.

Тактичні шаблони проектування в доменно-орієнтованому проектуванні (DDD)

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

спробуйте зловити java

Давайте розглянемо деякі з ключових тактичних шаблонів проектування в DDD:

1. Суб'єкт

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

Наприклад, у банківській програмі aBankAccount>юридична особа може мати такі властивості, як номер рахунку, баланс і власник, а також методи внесення, зняття або переказу коштів.

2. Об'єкт значення

Об’єкт значення – це об’єкт домену, який представляє концептуально незмінне значення. На відміну від сутностей, об’єкти-значення не мають чіткої ідентичності та зазвичай використовуються для представлення атрибутів або властивостей сутностей. Об’єкти цінностей можна порівняти за рівністю на основі їх властивостей, а не їх ідентичності.

Наприклад, aMoney>об’єкт value може представляти певну суму валюти, інкапсулюючи такі властивості, як тип і сума валюти.

3. Агрегатний

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

Наприклад, у системі електронної комерції анOrder>агрегат може складатися з сутностей, якOrderItem>іCustomer>, зOrder>сутність, що служить коренем сукупності.

4. Репозиторій

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

Наприклад, aCustomerRepository>може надавати методи для запитів і зберіганняCustomer>сутності.

5. Фабрика

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

Наприклад, aProductFactory>може відповідати за створення екземплярівProduct>сутності з конфігураціями за замовчуванням.

6. Обслуговування

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

Наприклад, анOrderService>може надавати методи обробки замовлень, застосування знижок і розрахунку вартості доставки.

Переваги доменно-керованого дизайну (DDD)

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

Проблеми доменно-орієнтованого проектування (DDD)

• Складність :
  • DDD може внести складність, особливо у великих і складних областях.
  • Точне моделювання складних бізнес-доменів вимагає глибокого розуміння предметної області та може включати роботу з двозначністю та невизначеністю. Ефективне управління цією складністю вимагає ретельного планування, співпраці та досвіду.
• Повсюдне прийняття мови :
  • Створення та підтримка повсюдної мови — спільного словникового запасу, який точно представляє концепції домену — може бути складним завданням. Для визначення та узгодження термінів і значень домену потрібна співпраця між розробниками та експертами домену.
  • Досягнення консенсусу щодо повсюдної мови може вимагати подолання комунікаційних бар’єрів і узгодження розбіжностей у термінології та перспективах.
• Обмежене вирівнювання контексту :
  • У великих і складних областях різні частини області можуть мати різні моделі та обмежені контексти. Вирівняти ці обмежені контексти та забезпечити узгодженість між ними може бути складно.
  • Це вимагає чіткої комунікації, співпраці та координації між командами, які працюють над різними частинами домену, щоб уникнути неузгодженості та конфліктів.
• Технічна складність :
  • Для ефективного впровадження принципів і шаблонів DDD може знадобитися впровадження нових технологій, фреймворків і архітектурних підходів. Інтеграція DDD із існуючими системами чи застарілими кодовими базами може бути складною та може вимагати рефакторингу або перепроектування існуючого коду для відповідності принципам DDD.
  • Технічні проблеми, такі як продуктивність, масштабованість і ремонтопридатність, повинні бути ретельно розглянуті, щоб забезпечити успішне впровадження DDD.
• Опір змінам :
  • Запровадження DDD може наштовхнутися на опір з боку членів команди, які звикли до традиційних підходів до розробки або які вважають DDD надто складним або непрактичним.
  • Щоб подолати опір змінам, потрібні ефективна комунікація, освіта та лідерство, щоб продемонструвати переваги DDD і вирішити проблеми та скептицизм.
• Надмірна інженерія :
  • Існує ризик надмірного проектування під час застосування DDD, коли команди надто зосереджені на моделюванні складних концепцій домену та введенні непотрібних абстракцій або складності. Дотримання правильного балансу між простотою та виразністю має вирішальне значення, щоб уникнути надмірного ускладнення дизайну та реалізації.

Випадки використання доменно-керованого дизайну (DDD)

• Фінанси та банківська справа :
  • У фінансовому секторі DDD можна використовувати для моделювання складних фінансових інструментів, операцій і нормативних вимог. Завдяки точному представленню таких понять домену, як рахунки, транзакції та портфелі, DDD допомагає забезпечити цілісність і послідовність фінансових систем. Це також дозволяє краще керувати ризиками, дотримуватись нормативних вимог і звітувати.
• Електронна комерція та роздрібна торгівля :
  • Платформи електронної комерції часто мають справу зі складними концепціями домену, такими як каталоги продуктів, управління запасами, ціноутворення та замовлення клієнтів. DDD може допомогти ефективно моделювати ці концепції, забезпечуючи такі функції, як персоналізовані рекомендації, динамічне ціноутворення та спрощену обробку замовлень.
• Охорона здоров'я та науки про життя :
  • У сфері охорони здоров’я DDD можна використовувати для моделювання карт пацієнтів, медичних діагнозів, планів лікування та робочих процесів у сфері охорони здоров’я. Завдяки точному відображенню таких понять домену, як демографічні дані пацієнтів, історії хвороби та клінічні протоколи, DDD дозволяє розробляти надійні системи електронних записів про стан здоров’я (EHR), платформи медичних зображень і телемедичні програми.
• страхування :
  • Страхові компанії керують різними продуктами, політиками, претензіями та процесами андеррайтингу. DDD може допомогти змоделювати ці складні концепції домену, забезпечуючи такі функції, як керування політикою, обробка претензій, оцінка ризиків і актуарний аналіз.
• Нерухомість та управління майном :
  • Управління нерухомістю та майном передбачає роботу з різноманітною нерухомістю, орендою, орендарями, запитами на технічне обслуговування та фінансовими операціями. DDD може допомогти ефективно моделювати ці концепції домену, забезпечуючи такі функції, як списки нерухомості, управління орендою, портали орендарів і відстеження активів.

Реальний приклад доменно-керованого дизайну (DDD)

Постановка проблеми

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

q4 місяці

Всюдисуща мова

1. Користувач : відноситься до осіб, які замовляють поїздки через платформу RideX.
2. Водій : відноситься до осіб, які надають поїздки користувачам через платформу RideX.
3. Запит на поїздку : представляє запит користувача на поїздку із зазначенням таких деталей, як місце посадки, пункт призначення та параметри поїздки.
4. кататися : представляє один екземпляр поїздки, включаючи такі деталі, як місця посадки та висадки, тариф і тривалість.
5. Статус поїздки : відображає поточний статус поїздки, як-от Запитано, Прийнято, Виконується або Завершено.

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

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

Сутності та об’єкти значень

1. Суб'єкт користувача : представляє зареєстрованого користувача платформи RideX із такими властивостями, як ідентифікатор користувача, електронна адреса, пароль і платіжна інформація.
2. Об'єкт драйвера : представляє зареєстрованого водія на платформі RideX із такими властивостями, як ідентифікатор водія, деталі автомобіля та статус водія.
3. Сутність запиту на поїздку : представляє запит користувача на поїздку, включаючи такі властивості, як ідентифікатор запиту, місце посадки, пункт призначення та параметри поїздки.
4. Ride Entity : представляє окремий екземпляр поїздки, включаючи такі властивості, як ідентифікатор поїздки, місця посадки та висадки, вартість проїзду та статус поїздки.
5. Об'єкт значення розташування : представляє географічне розташування з такими властивостями, як широта та довгота.

Агрегати

1. Ride Aggregate : складається з об’єкта Ride як сукупного кореня разом із пов’язаними об’єктами, такими як об’єкти Ride Request, User і Driver. Ride Aggregate містить логіку керування життєвим циклом поїздки, включаючи обробку запитів на поїздку, призначення водіїв і оновлення статусу поїздки.

Репозиторій

1. Ride Repository : надає методи для запитів і зберігання об’єктів, пов’язаних із поїздками, наприклад отримання деталей поїздок, оновлення статусу поїздок і збереження даних, пов’язаних із поїздками, у базі даних.

Послуги

1. Служба призначення поїздок : Відповідає за призначення доступних водіїв для запитів на поїздки на основі таких факторів, як доступність водія, близькість до місця посадки та вподобання користувача.
2. Платіжна служба : обробка платежів за виконані поїздки, розрахунок тарифів, обробка платежів і оновлення платіжної інформації користувачів і водіїв.

Події домену

1. RideRequestedEvent : представляє подію, яка запускається, коли користувач запитує поїздку, містить таку інформацію, як деталі запиту на поїздку та ідентифікатор користувача.
2. RideAcceptedEvent : представляє подію, яка запускається, коли водій приймає запит на поїздку, що містить таку інформацію, як ідентифікатор поїздки, ідентифікатор водія та місце посадки.

Приклад сценарію

1. Користувач, який запитує проїзд : користувач надсилає запит на поїздку, вказуючи місце посадки, пункт призначення та вподобання щодо поїздки. RideX створює нову сутність запиту на поїздку та запускає RideRequestedEvent.
2. Водій приймає поїздку : водій приймає запит на поїздку від платформи RideX. RideX оновлює статус поїздки на Accepted, призначає водія для поїздки та ініціює RideAcceptedEvent.
3. Виконується поїздка : користувач і водій координують поїздку, при цьому статус поїздки змінюється з Прийнято на Виконується, коли водій досягає місця посадки.
4. Завершення поїздки : після досягнення пункту призначення статус поїздки оновлюється на Завершено. RideX розраховує тариф, обробляє платіж і відповідно оновлює платіжну інформацію користувача та водія.