Domain-Driven Design на практиці

Технології допомагають нам вирішувати проблеми бізнесу та створювати дійсно корисний продукт. 

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

Domain-Driven Design — це підхід, що фокусується на вивченні предметної області всього бізнесу або його окремих процесів.  

Отже, Domain-Driven Design вчить нас спілкуватися із замовником мовою бізнесу (а не програмування).  

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

03 лютого ми провели вебінар, під час якого поговорили про те, що ж таке Domain-Driven Design та як його впроваджувати у життя на практиці.  

Як використовувати цей підхід та з чого починати роботу — пояснює Ігор Скостарєв, Lead Java-інженер в EPAM із понад 12-річним досвідом розробки на різноманітних проєктах. 

В житті Ігор тривалий час захоплюється катанням на сноуборді. Можливо, саме тому про Domain-Driven Design він вирішив розповісти на конкретному (і цікавому!) прикладі зимового курорту. 

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

Далі Ігор розглядає три основні стовпи Domain-Driven Design: обмежений контекст, стратегічні і тактичні патерни. 

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

Згідно закону Конвея, будь-яка система, яку ми розробляємо, повторює комунікації всередині установи. Саме цим законом керується Ігор у випадку з зимовим курортом.  Створення трьох сценаріїв використання з різними ізольованими контекстами позбавляє нас ситуації, в якій «нічого не працює, поки все не працює». 

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

Таким чином, ми: 

• Зрозуміли, як при наявності споріднених контекстів можна пов'язати сервіси.  
• З'ясували, яка різниця між патернами «замовник/постачальник» та «конформіст». 
• Розглянули адаптацію моделі одного сервіса до моделі іншого. 
• Згадали про сторонні сервіси. 

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

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

Тут ми переходимо до тактичних патернів.  

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

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

Пояснюючи процес взаємодії сутностей, Ігор називає два типи сервісів — доменний та сервіс додатка, а також дає поради щодо Їх використання. 

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

На завершення, поговорили про антипатерни: анемічну доменну модель, одержимість примітивами, витік ID та повернення моделі «як вона є». 

Під час вебінару ми спробували показати, що підхід Domain-Driven Design має чимало переваг, а його використання простіше, ніж здається на перший погляд.  

І, як завжди, дякуємо, що ви з нами!