Přinést jasnost do vašeho monolit s Ohraničené Kontextech

Podívejte se na video z této řeči od ElixirConf 2017 níže

Monolitické aplikace jsou skvělé, když můžete začít budování vaší společnosti, ale jak čas postupuje, se stávají obtížné udržet. Tyto kódové základny, jak rostou, se snadno stávají velkými kuličkami bláta.

Při budování rozsáhlých aplikací v rámcích jako Kolejnice, velmi úmluvy-nad-konfigurace, principy návrhu, který dělal Kolejnice takovou radost používat begin dostat do cesty, když aplikace roste v působnosti. Mohou být zažívá stejné bolesti, jako dobře, pokud:

• Refactoring je obtížné a zdlouhavé, protože metod a tříd závisí na příliš mnoho jiných třídách,
• máte někdy-rostoucí seznam podnikatelských objektů, které je obtížné udržet v hlavě. Ve skutečnosti, nikdo se zdá být schopni pochopit systém jako kompaktní celek
• Změna kódu v jedné oblasti kódu vede k nečekané a nezamýšlené vedlejší účinky v jiných oblastech kódu, protože to je snadné volat na globální služby a objekty

V našem posledním povídání spolu, diskutovali jsme o rozvojových Všudypřítomné Jazyk spolu s obchodními odborníky a váš vývojový tým na pomoc svůj tým více spolupracovat. Dnes na tom budeme stavět zavedením nových nástrojů pro návrh řízený doménou (DDD). Poté představíme novou strukturu složek pro vaše aplikace Rails a připravíme je na budoucnost, ve které je vaše aplikace méně propojená a soudržnější. Pojďme začít!

Pojďme mluvit domén

hlavní zásadou v DDD je, že software budete stavět musí úzce odrážet (podnikání) domény organizace, která ho staví. Proto musíme udělat nějaké domácí úkoly, abychom pochopili obchodní doménu vašeho softwaru.

doména je to, co podnik dělá, a kontext toho, jak to dělá.

pojďme se podívat na náš Delorean příklad z předchozího příspěvku. V něm je společnost uváděna na trh jako Uber pro cestování časem. Jeho “doménou” (“co dělá”) je tedy cestování v čase. Součástí domény je také” jak ” toho, jak to dělá – partnerstvím řidičů, kteří vlastní Delorská vozidla cestující časem, s cestujícími, kteří chtějí cestovat v čase.

Se dostat na další nuance v oblasti podnikání, DDD zavádí další pojem, tzv. Subdomény:

Subdoména představuje menších skupin nebo jednotek, z podnikání, které spolupracují v den-to-den k dosažení obchodních cílů.

Delorean je rozdělen do několika týmů v rámci společnosti. Podívejme se na dva z nich a uvidíme, za co jsou zodpovědní:

	Výlet Platforma tým	Finanční Operace tým
Mise	Design a podpora systémů, které trasy cesty a připojit ovladače pro cestující	Spravovat systémy, které zahrnují finanční instituce a kreditní karty procesory
Odpovědnost	Připojení cestujících k řidiči Trasy řidiče, aby jejich další cíl Informovat cestující přijíždějící řidiči Upozornění řidičům, aby nové cestující	Proces výplaty pro ovladače Udržovat systém-široký transakční historie pro audit Vytvořit finanční zprávy Proces kreditní kartu poplatků pro cestující

Každé z těchto dvou skupin animovat podnikání odpovědnost, nebo subdomény. Pojmenujme je Ridesharing Experience a Ecommerce.

nyní máme obecnou ilustraci podnikání a dvou jeho jednotek, které mu pomáhají fungovat v každodenním životě. Doména a subdoména jsou způsoby, jak modelovat problémový prostor vašeho podnikání – a jak se chová k plnění těchto rolí. Je pravděpodobné, že vaše obchodní org graf bude úzce odrážet subdomény vašeho podnikání. Ve skutečném světě, vymezení může být méně jasné-týmy mohou být zodpovědné za více, překrývající se subdomény.

vyplňte tento diagram několika dalšími subdoménami v Delorean business:

• subdoména zákaznické podpory: řešení vstupenek zákaznické podpory přicházejících prostřednictvím e-mailu
• marketingová subdoména: výkonný e-mail marketing kampaně a marketing kupón kódy
• Identity subdoménu: Jak systém sleduje každého uživatele a jeho/její identifikační údaje

Vymezené Kontexty, v řešení prostoru

Tento diagram před námi nyní odráží obchodní cíle společnosti, rozdělit na logické celky, které (snad) dosáhnout svých cílů v reálném světě. Nyní překryjeme softwarové systémy, které dosahují těchto cílů, přes tento diagram. Tyto softwarové systémy jsou popsány jako ohraničené kontexty:

ohraničený kontext je systém, který splňuje cíle podnikání v reálném světě.

jakýkoli z našich softwarových systémů (jako je webová služba nebo webová aplikace), které fungují jako konkrétní instance v reálném světě, jsou považovány za ohraničené kontexty.

Technicky vzato, Ohraničený Kontext, ve DDD-mluvit je určité hranice, v rámci vaší domény, že váš Slovník z vašeho Všudypřítomné Jazyk může vztahovat pouze – myšlenka je, že různé Subdomény mohou mít konkurenční či konfliktní definice pojmů. Tento příspěvek se nebude zabývat jazykovými nuancemi ohraničeného kontextu. Pro další čtení, viz vysvětlení Martina Fowlera o ohraničených kontextech.

nyní se stává, že v Delorean jsou všechny tyto subdomény implementovány v jednom systému-jedna velká koule monolitu bahenních kolejnic. Nakreslíme modré pole kolem subdomén, jejichž funkce jsou implementovány softwarovým systémem. V tomto případě začneme s výše uvedenými kolejnicemi monolith:

protože je to monolit, dělá v podstatě všechno – a tak tady, požírá všechny ostatní subdomény v diagramu.

nezapomeňte – máme několik dalších softwarových systémů, které jsme zde nemodelovali. A co všechny pěkné integrace třetích stran, které společnost používá? Jedná se také o softwarové systémy. Nakreslíme je jako modré krabice.

mimochodem – to, co jsme nakreslili tady je Kontext Mapě – diagram, který se mísí obchodní cíle a konkrétní implementace softwarových systémů. Je to užitečné pro posouzení rozložení země vašich softwarových systémů a vizualizaci závislostí mezi týmy.

nyní je to rozumné a čisté, ale žijeme v reálném světě a software v reálném světě zřídka vypadá konzistentně a soudržně. Pokud jste vytvořili aplikaci Rails podle konvencí out-of-the-box, vaše aplikace interně postrádá seskupení nezbytná k vizualizaci vaší aplikace v jejích složkách. V realitě, Delorean codebase vypadá něco podobného:

jde – Kolejnice nebude vymáhat jakékoliv organizační omezení na našich softwarových systémů – což znamená, že logické obchodních jednotek (naše subdomény), které naznačují, oddělené rozhraní – nejsou zhmotnil v kódu, což vede ke zmatku a rostoucí složitosti jak roky plynou.

velká myšlenka: Uspořádat Kolejnice kód do modulů, obchodní subdomény

I když vaše Ruby tříd v aplikaci pravděpodobně žít v globálním jmenném prostoru, mohou být snadno vytáhl do modulů. Naším cílem je vytvořit logické skupiny doménového kódu, které lze izolovat do samostatných komponent.

jedním z cílů návrhů řízených doménou je mít individuální mapování z subdomény do ohraničeného kontextu.

OK, co to znamená? Podívejme se na některá doporučení spolu s příklady.

Invertovat struktury složek do bytu domény orientované seskupení

možná Si vzpomínáte, že po Kolejích úmluv nás vede do složky hierarchie tříd skupiny rolí:

Pojďme se přesunout vše do nového adresáře struktura: pojďme místo toho seskupit funkčnost podle domény. Začneme s první variantou, kterou budu nazývat seskupením orientovaným na plochou doménu.

Modulujte třídy

Dále budete chtít modulovat třídy z toho, co byly předtím. Protože Řidič třída spadá pod Spolujízda domény, budeme jej přidat do Spolujízda modulu:

Budete chtít udělat pro každou třídu přesunout do app/domains ploché adresářové struktury.

Reference související modely plné jméno třídy

Navíc, musíte změnit nastavení ActiveRecord vzoru sdružení, se odkazovat na třídu plnou, modulized path:

Mějte řadiče až do dnešního dne, kde najít své nově modulized názory

Budete také muset vložit tento malý kousek nechat tras od správce vědět, kde hledat názory:

Tady je to super věc: nemusíte přesunout všechny své kód najednou. Můžete vybrat jeden malý domény v aplikaci, nejzralejší oblasti kódu nebo oblasti, které budete mít nejlepší pochopení kolem sebe, a začít přesouvat své zájmy do jedné domény složky, to vše při ponechání stávající kód v klidu, dokud je připraven k nastěhování.

nyní jsme provedli několik malých kroků k dosažení architektonické jasnosti v naší aplikaci. Podíváme-li se nyní, naše modulární struktury složek nám pomohly seskupeny náš kód jako tak:

Pod kapotou, naše aplikace může vypadat takhle:

to, Co funguje dobře s tímto přístupem?

1. Tam je méně hluku v každý soubor, adresář – pomocí seskupení jako soubory domain-specificity, najdeme přírodní organizační bod
2. entity, které zůstávají v každé doméně složky jsou vysoce soudržné – s největší pravděpodobností přirozeně tendenci komunikovat s navzájem a objevují přirozeně s sebou
3. Subjekty, které k sobě nepatří, jsou nyní odděleny (volnější-spolu)
4. Pokud máte inženýrské týmy, které pracují společně Subdomény-odpovědnost, tito inženýři nyní mohou pracovat ve více efektivní, izolované módy. Volnější spojka umožňuje tyto týmy, aby se změny s jistotou, že nebudou zavádět regrese nebo sloučit konflikty zpět do codebase
5. fázi se nyní nachází v dlouhodobém horizontu začít pohybující se každá z těchto domén složky do samostatného software služby (o tom více v budoucím blogu)

Pokud chcete nějaké další pokyny do této složky struktury, vyvinul jsem ukázkové aplikace, která exponáty této domény orientované na strukturu složek: http://github.com/andrewhao/delorean. Podívejte se a dejte mi vědět, co si myslíte.

co jsme se naučili?

v naší společné době jsme se dozvěděli o konceptech návrhu řízených doménou kolem domén a subdomén. Naučili jsme se vizualizovat naše softwarové systémy jako ohraničené kontexty na kontextové mapě, která nám ukázala oblasti systému, které k sobě patří jako koherentní části.

Končí na praktické vědomí, jsme ilustruje, jak Kolejnice soubory a složky by mohl být “obrácené” a reimagined jako domény-první seskupení.

v mém dalším příspěvku budeme pokračovat v diskusi v nadcházejícím blogu o tom, jak dále oddělit náš Doménově orientovaný Rails kód s událostmi domény a nakonec se dostat do země mikroservisů.