Пропустити навігацію EPAM

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

Кейси
  • Java
  • TechTalk

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

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

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 має чимало переваг, а його використання простіше, ніж здається на перший погляд.  

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

Підписатися на новини

Чудово! Ми вже готуємо добірку актуальних новин для вас :)

Вибачте, щось пішло не так. Будь ласка, спробуйте ще раз.

*Будь ласка, заповніть обов’язкові поля

Вакансії EPAM Ukraine у Київ | Львів | Харків | Дніпро | Вінниця | Івано-Франківськ | Одеса | Чернівці | Хмельницький | Рівне | Ужгород | Тернопіль | Луцьк за напрямком Java | JavaScript | .NET | DevOps | Experience Design | Software Testing | Business Analysis | Python| Big Data | Mobile | Solution Architect | Ruby on Rails у містах за напрямком Java вакансії Київ | Java вакансії Харків | Java вакансії Львів | Java вакансії Вінниця | Java вакансії Одеса | Java вакансії Івано-Франківськ | Java вакансії Чернівці | Java вакансії Хмельницький | Java вакансії Рівне | Java вакансії Ужгород | Java вакансії Тернопіль | Java вакансії Луцьк | JavaScript вакансії Київ | JavaScript вакансії Харків | JavaScript вакансії Львів | JavaScript вакансії Вінниця | JavaScript вакансії Одеса | JavaScript вакансії Івано-Франківськ | JavaScript вакансії Чернівці | JavaScript вакансії Хмельницький | JavaScript вакансії Рівне | JavaScript вакансії Ужгород | JavaScript вакансії Тернопіль | JavaScript вакансії Луцьк | DevOps вакансії Київ | DevOps вакансії Харків | DevOps вакансії Львів | DevOps вакансії Вінниця | DevOps вакансії Одеса | DevOps вакансії Івано-Франківськ | DevOps вакансії Чернівці | DevOps вакансії Хмельницький | DevOps вакансії Рівне | DevOps вакансії Ужгород | DevOps вакансії Тернопіль | DevOps вакансії Луцьк