Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Що таке Domain-Driven Design та на якому етапі варто його впроваджувати в продукт

Усім привіт! Мене звати Борис Кущ, і я Head of Product Management Legion у британській фінтех-компанії Wirex. Оскільки продукт, який розвиває наша команда, поєднує цифрові й традиційні валюти в одному застосунку і надає доступ користувачам у різних юрисдикціях, для нас важлива його безперебійна й стабільна робота та можливість швидко здійснювати десятки релізів на день. Розвʼязувати ці задачі нам допомагає Domain-Driven Design (DDD) архітектури додатка.

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

Що таке домен і доменна організаційна структура бізнесу

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

Прикладами компаній, які поєднали в один бізнес декілька доменів і успішно працюють на міжнародному ринку є Google, Amazon, українська «Нова Пошта».

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

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

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

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

Як DDD впливає на реліз нового функціоналу

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

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

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

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

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

Як імплементувати DDD і скільки на це потрібно часу

Все залежить від вихідних даних: розміру команди, самого продукту, складності архітектури, яка вже існує. Треба розуміти важливі моменти: якщо є legacy, краще буде перевести певні частини на мікросервіси — чи готовий бізнес виділити час для цього?

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

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

Водночас бізнес захоче бачити продукт у девелопменті, можливо — з додатковими фічами, і все це треба буде підтримувати. Так або інакше, бізнес, що розростається, приходить до необхідності полегшувати систему. Що раніше це відбудеться, то простішим та дешевшим буде процес переходу.

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

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

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

Які челенджі можуть з’явитися на шляху впровадження DDD

Серед челенджів переходу на DDD ми вже згадували витрати часу та матеріальних ресурсів, паралельність поставок поточного продукту з його підтримкою і «розпил» монолітної архітектури на мікросервіси.

Та однією зі складностей може бути неготовність до змін з боку команди. Варто бути готовими до ймовірності спротиву — всі люди різні, комусь зручно працювати і з legacy.

Тож, по-перше, челенджі можливі з людьми. Це може призвести до певного «очищення» команди, але, як правило, не більше 10%. Проактивні інженери, які прагнуть покращення бізнес-рішень замість «полірування коду», ймовірно зустрінуть такі зміни позитивно. На рівні Head Engineering або Head of Implementation навряд будуть пасивні герої.

Челенджі можуть виникати і з бізнесом, оскільки перехід може зайняти багато часу, а час — це гроші. Можливі також структурні та фінансові зміни: памʼятайте, що вам буде необхідно розділити вже усталену команду на доменні області. Монолітна архітектура — це умовний оупенспейс, де всі працюють з усіма й до цього звикли; вам же доведеться «розсадити» старих друзів по окремих кімнатах. Це має бути дуже обдуманий підхід, адже розподіл моноліту на сервіси, а однієї великої команди — на окремі, є по суті певною зміною технічної структури компанії.

Та попри можливі труднощі, в результаті бізнес матиме прозоріший підхід до девелопменту, а окремі команди з 3-6 людей матимуть чітко визначені зони відповідальності (це 100% про agile, спринти, коли буде повне розуміння того, яку саме проблематику вирішує команда).

DDD і фінтех: як ця надбудова вплинула на галузь

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

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

Коли команда вже використовує принципи DDD, масштабування бізнесу відбувається простіше. Так, при виході на ринок США геоекспансія стала для нас технічно простою задачею, оскільки команди розширяли конфігурацію новим значенням для ще однієї локації.

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

Завдяки DDD нам було достатньо внести невеликі зміни у коді. Так, кожна команда усвідомлювала, що саме змінюється завдяки розумінню глобальних бізнес-цілей, тому велика подія виходу на новий ринок з технічної точки зору звучала як «включити X, Y, Z продукти з 1, 2, 3 параметрами, локація — USA».

Які уроки ми винесли під час впровадження DDD

Головний челендж — показати бізнесу, у чому переваги DDD підходу. Як це буде працювати, яку мету ми переслідуємо, як це спростить реліз функціонала і комунікацію. Відштовхуватися завжди краще від проблематики. Наприклад, коли є складність в релізі, гарним аргументом буде такий: «Ми можемо прискоритись в Х разів — не 2-3, а значно швидше».

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

Проблема, з якою стикнулись ми при переході з моноліту у Wirex — це коректне оцінювання задач. Ми вважали, що все прорахували й були впевнені у витратах часу, та при цьому з оцінки X вона виросла до X2. У процесі переходу на мікросервісну архітектуру стало зрозуміло, що неможливо передбачити все, зокрема через виникнення нових задач.

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

Головна ж порада така: знайти ідеальний момент для вчасного переходу. Як зрозуміти, коли? Оцініть кількість субдоменів у вашому додатку. Їх 10? Точно пора, далі буде лише складніше. Якщо субдоменів 3-5 — це ідеальний час для переходу на DDD за умови, якщо ви й надалі плануєте розростання бізнесу.

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нормальна цікава стаття. Трохи стало зрозуміліше про DDD.

Много текста, и все не в тему.
DDD — это метод разбития сложной предметной области на регионы (домены), в которых действует одинаковая терминология. Например, нужно автоматизировать предприятие. Там есть отдел бухгалтерии, отдел логистики, и отдел кадров. В каждом отделе — свой жаргон, и когда бухгалтер заходит на кофе к логистам, она их не понимает.
Вот DDD предлагает в этом случае делать отдельный модуль для бухгалтерии, отдельный — для логистики, и отдельный — для кадров. Потому что просто тупо нельзя найти человека, которому в голову влезет все и сразу. А если найти — то он будет 5 лет только разбираться в процессах предприятия.
Ну и почитать доходчиво английским по белому в книжке, с которой все это началось:
Eric Evans (2003): Domain-Driven Design: Tackling Complexity in the Heart of Software.

он будет 5 лет только разбираться в процессах предприятия.

 це деяке перебільшення )) насправді бізнеси (одні) просто економлять на БА («та що там складного»), інші економлять на менеджменті («та що там складного»), то й виходить черт за шо в підсумку. Сленг — більшою частиною однаковий, бо всі вчяться з одних джерел, навіть якщо вони неформальні. Варіантів організації діяльності — обмежена кількість. та таке інше. Якщо ти як спеціаліст трешся в галузі років за п’ять, то незрозумілого зустрічається небагато. А те що зустрічається — результат «економії» (найняли студента/інтерна замість спеціаліста...)

Якщо уся контора (чи увесь простір дизайну) вкладається в один словник — то тут не потрібен DDD. Так само, як коли пишеться невелика програма — не треба замислюватись щодо використання кількох мов програмування чи мікросервісів.

А от якщо, наприклад, робиться IoT з серверною частиною, field gateway, та купою датчиків — то отримуєш зоопарк: тут і хардварщики з осцилографами, і ембедери на bare metal С, і роутерники з linux kernel & networking, і application logic на С++, і бекенд на джаві чи пітоні, і девопси. І от фіг хардваник зрозуміє девопса, чи навпаки.

Так само відбувається у складних корпораціях — працівники одного відділу не знають, як працює інший. От в ГлобалЛоджіку, наприклад, ХР добре розуміються на матодології ПМ? Чи ПМ розуміє документування мікросервісів? А треба написати систему, котра покриє усе, що відбувається в корпорації, і замінить одночасно і Джиру, і 1С. Ось це і є DDD — по суті, робити Джиру та 1С окремими модулями, а не намагатись зліпити їх до купи й написати одною командою.

[написав, а потім видалив. Пішов думати]

Жодного посилання на літературу, жодних загальноприйнятих термінів, не до місця втулені мікросервіси vs моноліт (DDD був описаний задовго до появи мікросервісів), згадка про поганих девів які тільки й тратять гроші на

«полірування коду»

.
Структури в статті взагалі 0.
ІМХО, не стаття а записки в чорновику людини яка перший раз почула про DDD від бізнес аналітика за пивом.

Підписатись на коментарі