Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
Предметно-орієнтоване проєктування (рідше проблемно-орієнтоване, англ. domain-driven design, DDD) — це підхід до моделювання складного об'єктно-орієнтованого програмного забезпечення. Переваги DDD полягають в наступному:
- Концентрація основної уваги на предметній області;
- Створення програмних моделей, які відображують глибоке розуміння предметної області.
Термін був вперше запроваджений в своїй книзі з однойменною назвою.
Основні визначення
- Домен: Предметна область, середовище, галузь. Предметна область, яку програміст використовує при створенні програмного забезпечення.
- Модель: Система абстракцій, яка описує окремі аспекти предметної області.
- Загальна мова: Мова побудована навколо моделі предметної області. Використовується як програмістами при написанні програмного забезпечення, так і іншими членами команди (експертами обраної галузі).
- Контекст: Середовище, в якому предмет або дія означує своє значення.
Необхідні умови для успішного застосування DDD
- Обрана галузь не повинна бути тривіальною
- Команда проєкту повинна розуміти об'єктно-орієнтоване програмування / дизайн
- Команді проєкту необхідно спілкуватися з експертами у обраній галузі (орієнтуватися в ній)
- Використання ітеративного процесу розробки програми
Концепція
Безперечно при проєктуванні бажано мати одну модель, яка повністю описує всю предметну область, але в реальності, для спрощення процесу розробки продукту, домен представляють у вигляді сполучення декількох взаємопов'язаних моделей.
Стратегічно дизайн програмного продукту являє собою сукупність принципів для підтримки цілісності моделі, постійний рефакторінг як засіб дистиляції моделі, та поєднання декількох моделей в одну схему
Обмежений контекст
Використання декількох моделей на різних рівнях проєкту. Даний підхід використовується для зменшення зв'язків між моделями, що виключає складність і заплутаність коду. Іноді буває незрозуміло, в якому саме контексті повинна використовуватися модель.
Тому: Треба точно визначити контекст, в якому використовується модель. Визначити межі використання даної моделі та її характеристики.
Безперервна інтеграція
Існує тенденція фрагментування моделі у випадку коли в одному обмеженому контексті працюють одразу декілька людей. Це спричиняє розпад системи на дрібніші контексти, що в кінцевому результаті призводить до втрати цінності моделі.
Тому: Треба постійно зливати код (мерджити), використовувати автоматизовані тести, приділяти увагу виробленню загальної мови в проєкті.
Карта контекстів
При роботі над кількома окремими моделями у великій групі, різні члени команди можуть не знати про сутність інших моделей, що ускладнює процес загальної збірки кінцевого продукту.
Тому: На етапі проєктування точно позначте, що саме виконує кожна модель і як вона взаємопов'язана з іншими моделями. У кінцевому результаті у вас повинна вийти мапа взаємозв'язків між моделями.
Будівельні блоки DDD
У книзі Domain-Driven Design,, сформульований ряд концепцій і практик. Так, наприклад, особлива увага приділяється значенню загальної мови. При проєктуванні моделі предметної області необхідно сформувати спільну мову предметної області для опису вимог до системи, яка працює однаково добре як для бізнес-користувачів або спонсорів, так і для розробників програмного забезпечення. Ця мова означується експертами в обраній галузі. Книга зосереджена на описі доменного шару, як одного із загальних шарів в об'єктно-орієнтованій системі з багатошаровою архітектурою. У DDD є засоби для висловлення, створення та вилучення моделей предметної області:
- Сутність: Категорія індивідуальних об'єктів, які залишаються незмінними на різних етапах програми, для яких атрибути не грають великого значення, а послідовність та ідентичність, які поширюється в житті усієї системи називаються сутностями.
Приклад: Більшість авіакомпаній відрізняють кожне посадкове місце унікально на кожному польоті. Кожне сидіння є entity в цьому контексті. Тим не менш, Southwest Airlines (або EasyJet / RyanAir для європейців) не робить різниці між кожним місцем, всі місця однакові. У цьому контексті місце насправді Value Object.
- Об'єкт значення: об'єкт, який містить атрибути, але не має концептуальної ідентичності. Він повинен розглядатися як незмінний об'єкт.
Приклад: Коли українці обмінюються гривнями, вони зазвичай не розрізняють унікальність купюр, вони стурбовані номінальною вартістю банкноти. У цьому контексті, гривня є об'єктом значення (Value object). Проте, НБУ може бути стурбована кожною унікальною гривнею, в цьому контексті — кожна гривня буде сутністю (Entity).
- Сукупність: Колекція об'єктів, які пов'язані між собою завдяки головній сутності (Root Entity), інакше відомій як Aggregate root. Коренева сутність колекції об'єктів гарантує узгодженість змін, що вносяться до сукупності, забороняючи зовнішнім об'єктам посилатися на членів колекції.
- Сервіс: Коли будь-яка операція концептуально не відноситься до будь-якого об'єкту, вона може бути реалізована в сервісі.
- Сховище: Отримання об'єктів предметної області повинно делегуватися в спеціалізовані сховища об'єктів. Це дає можливість підміняти місце збереження об'єктів.
- Фабрика: Створення об'єктів предметної області повинно бути делеговане до спеціалізованих фабрик. Це дає можливість підміняти реалізацію створення об'єктів.
Зв'язок з іншими ідеями
- Об'єктно-орієнтований дизайн
- В теорії DDD не повинен бути обмеженим лише об'єктно-орієнтованою моделлю. На практиці ж DDD прагне використовувати переваги потужної об'єктно-орієнтованої парадигми. Читач повинен знати, що об'єктна орієнтація не створена винятково для Об'єктно Орієнтованих мов програмування, але також може бути частиною функціонального програмування.
- Аспектно-орієнтоване програмування (AOP)
- АОП дозволяє легко відокремити технічні проблеми (такі як безпека, управління транзакціями, логування) з моделі предметної області і полегшує розробку та реалізацію моделей предметної області, що сконцентровані виключно на бізнес-логіці.
Посилання
- Evans, Eric (2004), Domain-Driven Design — Tackling Complexity in the Heart of Software, Addison-Wesley.
Посилання
- Evans, Eric, (presentation), InfoQ, архів оригіналу за 21 червня 2013, процитовано 1 липня 2013.
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Predmetno oriyentovane proyektuvannya ridshe problemno oriyentovane angl domain driven design DDD ce pidhid do modelyuvannya skladnogo ob yektno oriyentovanogo programnogo zabezpechennya Perevagi DDD polyagayut v nastupnomu Koncentraciya osnovnoyi uvagi na predmetnij oblasti Stvorennya programnih modelej yaki vidobrazhuyut gliboke rozuminnya predmetnoyi oblasti Termin buv vpershe zaprovadzhenij v svoyij knizi z odnojmennoyu nazvoyu Osnovni viznachennyaDomen Predmetna oblast seredovishe galuz Predmetna oblast yaku programist vikoristovuye pri stvorenni programnogo zabezpechennya Model Sistema abstrakcij yaka opisuye okremi aspekti predmetnoyi oblasti Zagalna mova Mova pobudovana navkolo modeli predmetnoyi oblasti Vikoristovuyetsya yak programistami pri napisanni programnogo zabezpechennya tak i inshimi chlenami komandi ekspertami obranoyi galuzi Kontekst Seredovishe v yakomu predmet abo diya oznachuye svoye znachennya Neobhidni umovi dlya uspishnogo zastosuvannya DDDObrana galuz ne povinna buti trivialnoyu Komanda proyektu povinna rozumiti ob yektno oriyentovane programuvannya dizajn Komandi proyektu neobhidno spilkuvatisya z ekspertami u obranij galuzi oriyentuvatisya v nij Vikoristannya iterativnogo procesu rozrobki programiKoncepciyaPaterni v Domain Driven Design ta vidnosini mizh nimi Bezperechno pri proyektuvanni bazhano mati odnu model yaka povnistyu opisuye vsyu predmetnu oblast ale v realnosti dlya sproshennya procesu rozrobki produktu domen predstavlyayut u viglyadi spoluchennya dekilkoh vzayemopov yazanih modelej Strategichno dizajn programnogo produktu yavlyaye soboyu sukupnist principiv dlya pidtrimki cilisnosti modeli postijnij refaktoring yak zasib distilyaciyi modeli ta poyednannya dekilkoh modelej v odnu shemu Obmezhenij kontekst Vikoristannya dekilkoh modelej na riznih rivnyah proyektu Danij pidhid vikoristovuyetsya dlya zmenshennya zv yazkiv mizh modelyami sho viklyuchaye skladnist i zaplutanist kodu Inodi buvaye nezrozumilo v yakomu same konteksti povinna vikoristovuvatisya model Tomu Treba tochno viznachiti kontekst v yakomu vikoristovuyetsya model Viznachiti mezhi vikoristannya danoyi modeli ta yiyi harakteristiki Bezperervna integraciya Isnuye tendenciya fragmentuvannya modeli u vipadku koli v odnomu obmezhenomu konteksti pracyuyut odrazu dekilka lyudej Ce sprichinyaye rozpad sistemi na dribnishi konteksti sho v kincevomu rezultati prizvodit do vtrati cinnosti modeli Tomu Treba postijno zlivati kod merdzhiti vikoristovuvati avtomatizovani testi pridilyati uvagu viroblennyu zagalnoyi movi v proyekti Karta kontekstiv Pri roboti nad kilkoma okremimi modelyami u velikij grupi rizni chleni komandi mozhut ne znati pro sutnist inshih modelej sho uskladnyuye proces zagalnoyi zbirki kincevogo produktu Tomu Na etapi proyektuvannya tochno poznachte sho same vikonuye kozhna model i yak vona vzayemopov yazana z inshimi modelyami U kincevomu rezultati u vas povinna vijti mapa vzayemozv yazkiv mizh modelyami Budivelni bloki DDDU knizi Domain Driven Design sformulovanij ryad koncepcij i praktik Tak napriklad osobliva uvaga pridilyayetsya znachennyu zagalnoyi movi Pri proyektuvanni modeli predmetnoyi oblasti neobhidno sformuvati spilnu movu predmetnoyi oblasti dlya opisu vimog do sistemi yaka pracyuye odnakovo dobre yak dlya biznes koristuvachiv abo sponsoriv tak i dlya rozrobnikiv programnogo zabezpechennya Cya mova oznachuyetsya ekspertami v obranij galuzi Kniga zoseredzhena na opisi domennogo sharu yak odnogo iz zagalnih shariv v ob yektno oriyentovanij sistemi z bagatosharovoyu arhitekturoyu U DDD ye zasobi dlya vislovlennya stvorennya ta viluchennya modelej predmetnoyi oblasti Sutnist Kategoriya individualnih ob yektiv yaki zalishayutsya nezminnimi na riznih etapah programi dlya yakih atributi ne grayut velikogo znachennya a poslidovnist ta identichnist yaki poshiryuyetsya v zhitti usiyeyi sistemi nazivayutsya sutnostyami Priklad Bilshist aviakompanij vidriznyayut kozhne posadkove misce unikalno na kozhnomu poloti Kozhne sidinnya ye entity v comu konteksti Tim ne mensh Southwest Airlines abo EasyJet RyanAir dlya yevropejciv ne robit riznici mizh kozhnim miscem vsi miscya odnakovi U comu konteksti misce naspravdi Value Object Ob yekt znachennya ob yekt yakij mistit atributi ale ne maye konceptualnoyi identichnosti Vin povinen rozglyadatisya yak nezminnij ob yekt Priklad Koli ukrayinci obminyuyutsya grivnyami voni zazvichaj ne rozriznyayut unikalnist kupyur voni sturbovani nominalnoyu vartistyu banknoti U comu konteksti grivnya ye ob yektom znachennya Value object Prote NBU mozhe buti sturbovana kozhnoyu unikalnoyu grivneyu v comu konteksti kozhna grivnya bude sutnistyu Entity Sukupnist Kolekciya ob yektiv yaki pov yazani mizh soboyu zavdyaki golovnij sutnosti Root Entity inakshe vidomij yak Aggregate root Koreneva sutnist kolekciyi ob yektiv garantuye uzgodzhenist zmin sho vnosyatsya do sukupnosti zaboronyayuchi zovnishnim ob yektam posilatisya na chleniv kolekciyi Servis Koli bud yaka operaciya konceptualno ne vidnositsya do bud yakogo ob yektu vona mozhe buti realizovana v servisi Shovishe Otrimannya ob yektiv predmetnoyi oblasti povinno deleguvatisya v specializovani shovisha ob yektiv Ce daye mozhlivist pidminyati misce zberezhennya ob yektiv Fabrika Stvorennya ob yektiv predmetnoyi oblasti povinno buti delegovane do specializovanih fabrik Ce daye mozhlivist pidminyati realizaciyu stvorennya ob yektiv Zv yazok z inshimi ideyamiOb yektno oriyentovanij dizajn V teoriyi DDD ne povinen buti obmezhenim lishe ob yektno oriyentovanoyu modellyu Na praktici zh DDD pragne vikoristovuvati perevagi potuzhnoyi ob yektno oriyentovanoyi paradigmi Chitach povinen znati sho ob yektna oriyentaciya ne stvorena vinyatkovo dlya Ob yektno Oriyentovanih mov programuvannya ale takozh mozhe buti chastinoyu funkcionalnogo programuvannya Aspektno oriyentovane programuvannya AOP AOP dozvolyaye legko vidokremiti tehnichni problemi taki yak bezpeka upravlinnya tranzakciyami loguvannya z modeli predmetnoyi oblasti i polegshuye rozrobku ta realizaciyu modelej predmetnoyi oblasti sho skoncentrovani viklyuchno na biznes logici PosilannyaEvans Eric 2004 Domain Driven Design Tackling Complexity in the Heart of Software Addison Wesley PosilannyaEvans Eric presentation InfoQ arhiv originalu za 21 chervnya 2013 procitovano 1 lipnya 2013