Domain-Driven Design: стратегічне проектування. Частина 1



Здрастуйте, хабрапользователи! У цій статті мова піде про предметно-орієнтованому проектуванні програмного забезпечення з використанням, в першу чергу, стратегічних шаблонів.

Даний підхід використовував Он Вернон у своїй книзі «Реалізація методів предметно-орієнтованого проектування». Мета написання цієї книги: дати можливість розробникам здійснити політ на літаку DDD (в дитинстві автор часто подорожував зі своєю родиною на невеликих літаках). Вид з висоти дає більш широке уявлення про проблеми моделювання, не даючи застрягти в різних технічних деталях. Спостерігаючи ландшафт DDD таким способом, можна усвідомити переваги як стратегічного, так і технічного проектування. Докладніше – під катом!

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

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

Основною метою застосування DDD є отримання високоякісної моделі програмного забезпечення, яка буде максимально точно відображати поставлені бізнес-цілі. Для реалізації цього потрібно об'єднання зусиль як розробників, так і експертів у предметній області. Створення дружної і згуртованої команди дозволяє отримати велику кількість переваг для бізнесу. Обмін знаннями між членами команди знижує шанси появи «таємного знання» про моделі, досягається консенсус між експертами предметної області стосовно різних понять і термінології, розробляється більш точне визначення і опис самого бізнесу.

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

Єдиний мови
Цей колективний мова термінів називається
єдиний мова
(Ubiquitous Language). Це один з основних і найбільш важливих шаблонів предметного-орієнтованого проектування. Це не бізнес жаргон, нав'язаний розробникам, а справжній мовами, створений цілісною командою – експертами предметної області, розробниками, бізнес-аналітиками і усіма, хто залучений до створення системи. Роль в команді не настільки істотна, оскільки кожен член команди використовує для опису проекту
єдиний мова
. Процес створення єдиної мови більш творчий ніж формальний, так як він, як і будь-який інший природний мову, постійно розвивається, а ті артефакти, які спочатку сприяли розробці корисних єдиної мови, з часом застарівають. У результаті залишаються тільки самі стійкі й перевірені елементи. Щоб перейти від експериментів до точних знань, Он Вернон у своїй книзі пропонує використовувати наступні способи:

  1. Створення діаграм фізичної та концептуальної предметної областей і нанесення на них позначок, що позначають імена і дії. Такі діаграми носять неформальний характер, тому немає сенсу використовувати формальне моделювання (UML).
  2. Створення глосарію з простими визначеннями, а також альтернативними термінами з оцінкою їх перспективності. Таким чином розробляються стійкі словосполучення єдиного мови.
  3. Створення документації замість глосарію. Ця документація буде містити неформальні діаграми або важливі поняття, пов'язані з програмним забезпеченням.
  4. Обговорення готових фраз з іншими членами команди, які не можуть відразу освоїти глосарій або інші письмові документи.
Так як код буде розвиватися досить швидко і його необхідно погоджувати з поточним варіантом єдиної мови, то можна пізніше відмовитися від діаграм, глосарію або іншої документації.

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

Наведу кілька прикладів з книги:

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



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

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

Обмежений контекст
Ця концептуальна межа називається
обмежений контекст
(Bounded context). Це друге за значимістю властивість DDD після єдиної мови. Обидва ці поняття взаємопов'язані і не можуть існувати один без одного.

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

  • У кожному обмеженому контексті існує тільки один
    єдиний мова
    .
  • Обмежені контексти є відносно невеликими, менше ніж може здатися на перший погляд.
    обмежений контекст
    досить великий тільки для єдиного мови ізольованою предметної області, але не більше.
  • Єдиний означає «всюдисущий» або «всюдисущий», тобто мова, на якій говорять члени команди і на якому виражається окрема модель предметної області, яку розробляє команда.
  • Мова є єдиним тільки в рамках команди, яка працює над проектом в єдиному обмеженому контексті.
  • Спроба застосувати
    єдиний мова
    в рамках усього підприємства або що гірше, серед кількох підприємств, закінчиться провалом.
Для прикладу, слід розглянути контраст між термінами зведення (ассount) в контексті банківських послуг і в літературному контексті:

Контекст банківських послуг

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

Літературний контекст

Зведення – це сукупність літературних виразів про одному або кількох подіях, що сталися за певний період часу → На сайті amazon.com продається книга Into Thin Air: A Personal Account of the Mt. Everest Disaster

Розрізнити типи зведень неможливо по іменах. Але їх можна розрізнити виключно за назвами їхніх концептуальних контейнерів, тобто відповідних обмежених контекстах.

Ці обмежені контексти відносяться до різних
предметним областям
. У наступному прикладі, одне і те ж ім'я використовується у межах однієї і тієї ж
предметної області
.

У деяких видавництвах книги проходять різні етапи життєвого циклу, тобто книга проходить різні
контексти
.

  • Розробка концепції та пропозиції до видання
  • Контракт з автором
  • Управління редакційним процесом
  • Розробка макету книги, включаючи ілюстрації
  • Переклад на інші мови
  • Випуск паперових та/або електронних версій книги
  • Маркетинг
  • Продаж книги реалізаторам та/або безпосередньо покупцям
  • Поставка примірників книги реалізаторам або покупцям
У цьому випадку, не існує єдиного способу розробки правильної моделі книги. Наприклад, до укладення контракту, назву книги залишається невизначеним і може змінитися в процесі редагування. Для маркетингу не потрібно більшість з артефактів літературної та технічної редакцій, за винятком обкладинок і анотацій, а для продажу книги необхідні тільки назва, розташування складу, кількість примірників, розмір і вагу. Щоб уникнути плутанини, в рамках підходу DDD необхідно використовувати окремі
обмежені контексти
для кожної із стадій життєвого циклу. Модель книги в кожному
контексті
значно відрізнялася від усіх інших. Кожна команда певного
обмеженого контексту
говорить про книгу і точно знає, чого хоче для свого
контексту
.

У наведеному вище прикладі використовуються різні
обмежені контексти
в рамках однієї
предметної області
.

Предметна область, предметна подобласть, смислове ядро
Предметна область
(Domain) – це те, що робить організація, і середовище, в якій вона це робить. Розробник програмного забезпечення для організації обов'язково працює в її
предметної області
. Слід розуміти, що при розробці моделі предметної області необхідно зосередитися певною
підобласті
, так як практично неможливо створити єдину, комплексну модель бізнесу навіть помірно складної організації. Дуже важливо розділяти моделі на логічні розділені
предметні підобласті
(Subdomain) всієї
предметної області
, відповідно до їх фактичної функціональності.
Підобласті
дозволяють швидше визначити різні частини
предметної області
, необхідні для вирішення конкретного завдання.

Також необхідно вміти визначати
смислове ядро
(Core domain). Це дуже важливий аспект підходу DDD.
Смислове ядро
– це
подобласть
, що має першорядне значення для організації. Зі стратегічної точки зору бізнес повинен виділятися своїм
смисловим ядром
. Більшість DDD проектів зосереджені саме на
смисловому ядрі
. Кращі розробники і експерти повинні бути задіяні саме в цій
підобласті
. Більшість інвестицій повинні бути спрямовані саме сюди для досягнення переваги для бізнесу і отримання найбільшої прибутку.

Якщо моделюється певний аспект бізнесу, який важливий, але не є
смисловим ядром
, то він відноситься до
службової підобласті
(Supporting subdomain). Бізнес створює
службову подобласть
, тому що вона має спеціалізацію. Якщо вона не має спеціального призначення для бізнесу, а потрібна для всього бізнесу в цілому, то її називають
неспеціалізованій подобластью
(Generic subdomain). Ці види
подобластей
важливі для успіху бізнесу, але не мають першочергового значення. Саме
смислове ядро
має бути реалізовано ідеально, оскільки воно забезпечує перевагу для бізнесу.

Це і є основа для стратегічного проектування при підході DDD.

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

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

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



Це тільки частина
предметної області
, а не вся
предметна область
, в якій працює організація. Простір завдань (смислове ядро і підобласті) необхідно проаналізувати. Модель закупівель, зображена на малюнку, являє собою рішення для
смислового ядро
. Модель предметної області буде реалізована в явному
обмеженому контексті
: контексті оптимальних закупівель. Цей
обмежений контекст
однозначно відповідає одній
підобласті
під назвою смислове ядро оптимальних закупівель. Ще один
обмежений контекст
під назвою контекст закупівель буде розроблений для уточнення технічних аспектів процесу закупівель і буде відігравати допоміжну роль по відношенню до контексту оптимальних закупівель. Вони забезпечують взаємодію з відкритим інтерфейсом системи ERP. Контекст закупівель і модуль закупівель ERP об'єднуються в службову подобласть закупівель. Сам модуль ERP є
неспеціалізованій подобластью
, оскільки її можна замінити на будь-яку іншу комерційну систему закупівель. Однак, вона стає
службової подобластью
, якщо її розглянути в поєднанні з контекстом закупівель в підобласті закупівель. У відповідність з малюнком, контекст оптимальних закупівель повинен взаємодіяти з контекстом товарних запасів, який управляє одиницями зберігання. Він використовує модуль товарних запасів ERP, який знаходиться в межах
службової підобласті
товарних запасів. ERP-додаток складається з різних модулів, які ми розглядаємо як логічні
підобласті
підобласті
товарних запасів і закупівель. Ці модулі і контексти запасів і закупівель об'єднуються в
службові підобласті
.

Отже, для оцінки простору задач в першу чергу необхідно:

  • Визначити, як виглядає стратегічне
    смислове ядро
  • Які концепції повинні розглядатися як частина
    смислового ядра
  • Перерахувати
    службові
    та
    неспеціалізовані підобласті
    .
Оцінка простору завдань впливає на оцінку простору рішень. Тут необхідно думати вже про наявних і нових системах і технологіях. Треба думати в термінах чітко отделимых фізичних
органічних контекстів
, для яких шукається
єдиний мова
. Слід:

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

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

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

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


Ця
карта контекстів
(Context map) відображає поточне положення справ, а не те, що буде в майбутньому. Необхідно уникати формальностей у процесі створення
карти
. Занадто велика кількість деталей тільки заважає процесу створення.

Природний хід подій – збіг меж контекстів з організаційним розподілом команди. Люди, які працюють разом, розділяють один загальний контекст моделі.

Після створення попередньої
карти контекстів
, її можна деталізувати шляхом визначення відносин між
контекстами
.

Існують такі відносини між
обмеженими контекстами
та окремими командами проекту:

  • партнерство
    (Partnership). Коли команди у двох
    контекстах
    досягають успіху і зазнають невдачі разом, виникає відношення співробітництва. Вони повинні співпрацювати в процесі еволюції своїх інтерфейсів, щоб враховувати потреби обох систем.
  • загальне ядро
    (Shared kernel). Загальна частина моделі та коду утворює тісний взаємозв'язок. Позначається чітка межа підмножини моделі предметної області, яку команди згодні вважати загальною. Ядро повинне бути маленьким. Воно не може бути змінена без консультації з іншою командою. Необхідно погоджувати
    єдиний мова
    команд.
  • розробка заказчки-постачальник
    (Customer-supplier development). Коли дві команди знаходяться у відношенні «нижчого і вищого», і команди вищестоящі враховують пріоритети нижчестоящих команд.
  • конформіст
    (Conformist). Коли дві команди знаходяться у відношенні «вищого і нижчого», причому вищестояща команда не має причин враховувати потреби нижчої команди. Нижча команда враховує складність трансляції між обмеженими контекстами, беззаперечно підкоряючись моделі вищої команди.
  • запобіжний рівень
    (Anticorruption layer). Якщо управління та комунікація не відповідають загальному ядру, партнера, або стосовно «Замовник-постачальник», то трансляція є складною. Нижчий клієнт повинен створити ізолюючий шар, щоб забезпечити свою систему вищестоящої системи в термінах своєї моделі предметної області. Цей рівень спілкується з іншою системою з допомогою існуючого інтерфейсу, не вимагаючи або майже не вимагаючи модифікацій іншої системи.
  • служба з відкритим протоколом
    (Open host service). Визначається протокол, який надає доступ до системи як до набору служб. Для обліку нових вимог інтеграції цей протокол розширюється і уточнюється.
  • загальнодоступну мову
    (Published language). Трансляція між моделями двох
    обмежених контекстів
    вимагає спільної мови. В якості середовища для комунікації використовується добре документований спільну мову, який може висловити необхідну інформацію про предметної області, виконуючи при необхідності переклад інформації з іншої мови на цей.
  • окреме існування
    (Separate ways). Якщо між двома наборами функціональних можливостей немає важливого відносини, їх можна повністю від'єднати один від одного. Інтеграція завжди дорого коштує, а вигоди бувають незначні.
  • великий грудку бруду
    (Big ball of mud). Існують системи, в яких моделі перемішані, а межі стерті. Необхідно намалювати кордон такої суміші і назвати її
    великий грудку бруду
    .
Приклад розробки
карти контекстів
можна взяти з статті Альберто Брандоліні Strategic Domain Driven Design with Context Mapping.

Спочатку малюється проста карта контекстів з кордонами і зв'язком між
обмеженими контекстами
:

У цих двох контекстах є відмінності в концепціях з однаковою назвою. Наприклад, Account в Web User Profiling – це обліковий запис користувача (логін і пароль). У той же час, для PFM Application (персональне управління фінансами) – це зведення, що описує поточний стан клієнта з точки зору банку. Іноді, як було зазначено вище, одна і та ж концепція може використовуватися в абсолютно різних
контекстах
, тим самим для них необхідно визначити різні моделі.


Наприклад, PayeeAccount – це той же BankingAccount, але з іншим поведінкою (можна отримати баланс). Таким чином буде створено окремий контекст обліку витрат (expense tracking). Також окремо, у наведеному прикладі, створюється контекст онлайн сервісів банку (on-line banking services) (такі сервіси, наприклад, як роздрукування виписок банку).


Після першого кроку створення
карти
, можна деталізувати всі відносини. У кожного відносини є напрямок. Вищестоящі (upstream) впливають на нижчі (downstream), але не факт, що вірно зворотне.

Деталізована
карта
виглядає ось так:


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

Так як контекст профайлів веб-користувачів використовується як готовий модуль і він постачається «як є», тут встановлюється відношення
конформіст
(нижчого підпорядковується вищестоящому).

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

Це простий приклад
карти контекстів
, на ділі вони бувають набагато складніше.

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

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

Спасибі за увагу!

Статтю підготували: greebn9k (Сергій Грибняк)wa1one (Володимир Ковальчук), silmarilion (Андрій Хахарев).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.