Domain-driven design (méně často domain-driven design , DDD) je soubor principů a schémat zaměřených na vytváření optimálních systémů objektů. Scvrkává se na vytváření softwarových abstrakcí nazývaných doménové modely . Tyto modely zahrnují obchodní logiku , která vytváří spojení mezi skutečnými podmínkami oblasti aplikace produktu a kódem.
Domain-Driven Design není specifická technologie nebo metodika. DDD je sada pravidel, která vám umožní dělat správná rozhodnutí o designu. Tento přístup vám umožňuje výrazně urychlit proces návrhu softwaru v neznámé oblasti.
Přístup DDD je užitečný zejména v situacích, kdy vývojář není odborníkem v oblasti vyvíjeného produktu. Například: programátor nemůže znát všechny oblasti, ve kterých je třeba vytvořit software , ale se správnou reprezentací struktury, prostřednictvím doménově orientovaného přístupu, může snadno navrhnout aplikaci založenou na klíčových bodech a znalosti pracovní oblasti. .
Tento termín poprvé představil E. Evans ve své stejnojmenné knize „Domain-Driven Design“ [1] .
V ideálním případě chcete mít při navrhování jediný model, který plně popisuje celou předmětnou oblast, ale ve skutečnosti je pro zjednodušení procesu vývoje produktu doména prezentována jako kombinace několika vzájemně propojených modelů.
Diagram aplikační architektury je popis jednoho nebo více doménových modelů a jejich vzájemných vztahů.
Použití několika modelů na různých úrovních projektu . Tento přístup se používá ke snížení různých vztahů mezi modely, což eliminuje složitost a složitost kódu . Někdy není jasné, v jakém kontextu by měl být model použit.
Řešení: Přesně definujte kontext, ve kterém je model používán. Určete hranice použití tohoto modelu a jeho charakteristiky.
Když na projektu pracuje velké množství lidí, existuje tendence rozdělit model na několik menších fragmentů. Čím více lidí, tím závažnější je tento problém. V konečném důsledku je integrita projektu ztracena.
Řešení: Neustálé kombinování částí kódu od různých vývojářů a ověřování funkčnosti prostřednictvím testování . To umožňuje všem vývojářům zůstat v jednom velkém konceptu.
Při práci na několika samostatných modelech ve velké skupině si různí členové týmu nemusí být vědomi entit jiných modelů, což komplikuje celkový proces montáže konečného produktu.
Řešení: Ve fázi návrhu přesně definujte, co každý model dělá a jak souvisí s ostatními modely. Nakonec byste měli skončit s modelovou mapou vztahů.
Při navrhování založeném na doménově orientovaném přístupu se používají následující koncepty:
Většina systémů pro podniky využívá rozsáhlé oblasti odpovědnosti. V DDD se tato nejvyšší úroveň organizace nazývá ohraničený kontext. Například fakturační systém velké telekomunikační společnosti může mít následující klíčové prvky:
Všechny výše uvedené prvky musí být zahrnuty do jediného nepřerušovaného systému. Při navrhování vynikají notifikační systém a bezpečnostní systém jako zcela odlišné věci. Systémy, ve kterých implementace nedokáže oddělit a izolovat ohraničené kontexty, často získávají architektonický styl , který v roce 1999 Brian Foot a Joseph Yoder vhodně pojmenovali „ Big Mudball “. [2]
Podstatou doménově specifického designu je konkrétní definice kontextů a omezení modelování v nich.
Nejjednodušší způsob, jak vyjádřit entity , je jako podstatná jména : lidé, místa, produkty atd. Entity mají jak osobnost, tak životní cyklus. V době návrhu byste měli o entitách uvažovat spíše jako o jednotkách chování než o jednotkách dat. Nejčastěji musí nějaká operace, kterou se pokoušíte přidat do modelu, přijmout nějaká entita, nebo se začne vytvářet nebo načítat nová entita. Ve volněji propojeném kódu můžete najít spoustu obslužných nebo řídicích tříd , které kontrolují entity zvenčí.
Hodnotový objekt je vlastnost, která je důležitá v doméně , kterou modelujete. Na rozdíl od entit nemají žádné označení; jednoduše popisují konkrétní entity, které již mají označení. Užitečnost hodnotových objektů spočívá v tom, že popisují vlastnosti entit mnohem elegantnějším a záměrnějším způsobem. Vždy stojí za to pamatovat na to, že hodnota objektu se během provádění celého programového kódu nikdy nemění . Po vytvoření již nelze provádět změny.
Agregát je zvláštní entita, ke které mají spotřebitelé přímý přístup. Použití agregátů umožňuje vyhnout se nadměrnému spojení objektů tvořících model. Tím se zabrání zmatkům a zjednoduší se struktura, protože to neumožňuje vytvoření těsně propojených systémů.
Někdy jsou v doméně operace nebo procesy, které nemají žádné označení nebo životní cyklus. Doménové služby poskytují nástroj pro modelování těchto konceptů. Jsou bezstavové a vysoce spřažené, často poskytují jedinou veřejnou metodu a někdy přetížení pro množinové operace. Pokud je v chování zahrnuto více závislostí a neexistuje způsob, jak v entitě najít vhodné místo pro hostitele tohoto chování, použije se služba. Samotný pojem „služba“ je sice ve vývojovém světě přeplněn různými významy, ale v tomto tématu znamená malou třídu , která nepředstavuje konkrétní osobu, místo nebo věc v navrhované aplikaci, ale zahrnuje nějaký druh procesů. . Použití služeb vám umožňuje vstoupit do vícevrstvé architektury a také integrovat několik modelů, což zavádí závislost na infrastruktuře. [3]
Ačkoli v konceptu by se doménově orientovaný design neměl omezovat na jakékoli reprezentace, v praxi se však využívají silné stránky objektově orientovaného programování . Jedná se o použití dědičnosti , zapouzdření , reprezentace jako metod a tříd. Je třeba mít na paměti, že doménově specifický přístup lze aplikovat nejen na OOP jazyky jako Java , C# nebo C++ , ale také na funkční jazyky jako F# , Erlang . Zvláště užitečné jsou jazyky, které podporují vytváření a používání vlastních jazyků specifických pro doménu , jako je Scala (viz také LOP ).
| Vývoj softwaru | |
|---|---|
| Proces | |
Koncepty na vysoké úrovni | |
| Pokyny |
|
Vývojové metodiky | |
| Modelky |
|
| Pozoruhodné postavy |
|