Tisztázza a monolitot Korlátozott Kontextusokkal

nézze meg az elixirconf 2017 beszélgetésének videóját az alábbiakban

a monolitikus alkalmazások nagyszerűek, amikor elkezdi építeni a cégét, de az idő előrehaladtával nehezen karbantarthatók. Ezek a kódbázisok, ahogy nőnek, könnyen Nagy Sárgömbökké válnak.

amikor az épület nagy alkalmazások keretek, mint a Rails, a nagyon konvenció-over-configuration tervezési elvek tette Rails ilyen öröm használni kezd útban, amikor az alkalmazás növekszik a hatálya. Lehet, hogy ugyanazokat a fájdalmakat tapasztalja, ha:

• a Refaktorálás nehéz és unalmas, mert a módszerek és az osztályok túl sok más osztálytól függenek
• egyre növekvő üzleti objektumok listája van, amelyeket nehéz a fejedben tartani. Valójában úgy tűnik, hogy senki sem képes megérteni a rendszert, mint egy összetartó egészet
• a kód egyik területén a kód megváltoztatása váratlan és nem szándékos mellékhatásokhoz vezet a kód más területein, mert könnyű felhívni a globális szolgáltatásokat és objektumokat

legutóbbi beszélgetésünkben megbeszéltük, hogy egy mindenütt jelen lévő nyelvet fejlesztünk ki az üzleti szakértőkkel és a fejlesztőcsapattal együtt, hogy segítsük a csapat szorosabb együttműködését. Ma erre fogunk építeni új Domain-vezérelt tervezési (DDD) eszközök bevezetésével. Ezután bevezetünk egy új mappastruktúrát a Rails alkalmazásokhoz, felkészítve őket egy olyan jövőre, amelyben az alkalmazás kevésbé összekapcsolt és összetartóbb. Lássunk hozzá!

beszéljünk domainekről

a DDD egyik alapelve, hogy az Ön által készített szoftvernek szorosan tükröznie kell az azt építő szervezet (üzleti) domainjét. Így meg kell csinálnunk néhány házi feladatot, hogy megértsük a szoftver üzleti domainjét.

a Domain az, amit a vállalkozás csinál, és annak kontextusa.

nézzük újra a Delorean példa az előző post. Ebben a társaságot Uberként forgalmazzák időutazási utakra. Így a ” domain “(a” mit csinál”) az időutazás Telekocsi. Szintén szerepel a Domain a “Hogyan”, hogyan csinálja – partneri vezetők, akik a saját időutazó Delorean járművek utasokkal, akik szeretnék, hogy időutazás utak.

ahhoz, hogy minél több árnyalatok az üzleti területen, DDD bevezet egy másik koncepció, az úgynevezett aldomain:

az aldomain a vállalkozás kisebb csoportjait vagy egységeit képviseli, amelyek napi szinten együttműködnek az üzleti célok elérése érdekében.

a Delorean több csapatra oszlik a vállalaton belül. Nézzünk meg kettőt közülük, és lássuk, miért felelősek:

	Trip Platform csapat	pénzügyi műveletek csapat
küldetés	tervezze meg és támogassa azokat a rendszereket, amelyek az utazásokat irányítják és a járművezetőket az utasokhoz kötik	pénzügyi intézményeket és hitelkártya-feldolgozókat érintő rendszerek kezelése
felelősség	az utasok csatlakoztatása a járművezetőkhöz irányítsa a vezetőt a következő célállomásra értesítse az utasokat az érkező sofőrökről figyelmeztesse a járművezetőket az új utasokra	kifizetések feldolgozása a járművezetőknek rendszerszintű tranzakciós előzmények fenntartása az ellenőrzéshez pénzügyi jelentések készítése hitelkártya-díjak feldolgozása az utasoknak

e két csoport mindegyike animál egy üzleti felelősséget, vagy aldomain. Nevezzük őket Telekocsi élménynek, illetve e-kereskedelemnek.

most van egy általános illusztráció az üzletről és két egységéről, amelyek segítik a mindennapi működést. A Domain és az aldomain a vállalkozás problématerületének modellezésére szolgál – és hogyan működik ezeknek a szerepeknek a teljesítése érdekében. Valószínű, hogy az üzleti szervezeti diagram szorosan tükrözi vállalkozásának aldomainjeit. A Való Világban a körvonalazások kevésbé egyértelműek lehetnek-a csapatok felelősek lehetnek a többszörös, átfedő aldomainekért.

töltsük ki ezt a diagramot néhány további aldomainnel a Delorean üzletben:

• ügyféltámogatási aldomain: az ügyfélszolgálati jegyek e-mailben történő beérkezésének megoldása
• Marketing aldomain: marketing e-mail kampányok és marketing kuponkódok kezelése
• Identity aldomain: hogyan követi nyomon a rendszer az egyes felhasználókat és azonosító adatait

Korlátozott kontextusok a megoldási térben

ez az előttünk lévő diagram most a vállalat üzleti céljait tükrözi, logikai egységekre osztva, amelyek (remélhetőleg) megvalósítják céljait a Való Világban. Most átfedjük azokat a szoftverrendszereket, amelyek ezeket a célokat teljesítik ezen a diagramon. Ezeket a szoftverrendszereket Korlátozott kontextusként írják le:

a korlátozott kontextus olyan rendszer, amely teljesíti az üzleti célokat a valós világban.

bármely szoftverrendszerünk (például egy webszolgáltatás vagy webalkalmazás), amely konkrét példányként működik a valós világban, Korlátozott kontextusnak minősül.

technikai szempontból a DDD-speak Korlátozott kontextusa egy olyan határ a tartományon belül, amelyet a mindenütt jelenlévő nyelv szószedete csak alkalmazhat – az az elképzelés, hogy a különböző Aldomaineknek versengő vagy egymásnak ellentmondó definíciói lehetnek. Ez a bejegyzés nem részletezi a korlátozott kontextus nyelvi árnyalatait. További olvasmányokért lásd Martin Fowler magyarázatát a korlátozott összefüggésekről.

most úgy történik, hogy a Deloreannél ezeket az aldomaineket egy rendszerben valósítják meg – egy nagy Sárgömb Monolith. Kék mezőt rajzolunk az aldomainek köré, amelyek funkcióit a szoftverrendszer valósítja meg. Ebben az esetben, kezdjük a fent említett sínek monolith:

mivel ez a monolit, alapvetően mindent megtesz – ezért itt a diagram összes többi aldomainjét megeszi.

ne felejtsük el – van néhány más szoftverrendszerünk is, amelyeket itt nem modelleztünk. Mi a helyzet az összes szép harmadik fél integrációval, amelyet a vállalat használ? Ezek is szoftveres rendszerek. Kék dobozként rajzoljuk őket.

mellesleg – amit itt rajzoltunk, az egy Kontextustérkép – egy diagram, amely ötvözi az üzleti célokat és a szoftverrendszerek konkrét megvalósításait. Hasznos a szoftverrendszerek földrajzi elhelyezkedésének felmérésére és a csapatok közötti függőségek megjelenítésére.

Nos, ez ésszerű és tiszta, de a való világban élünk, és a valós szoftverek ritkán jönnek ki következetesnek és koherensnek. Ha a Rails alkalmazást a dobozon kívüli konvenciók alapján építette fel, az alkalmazásból belsőleg hiányoznak azok a csoportosítások, amelyek szükségesek ahhoz, hogy az alkalmazást az alkotóelemeiben megjelenítse. A valóságban a Delorean kódbázis így néz ki:

a lényeg az, hogy a Rails nem kényszerít semmilyen szervezeti korlátozást szoftverrendszereinkre – ami azt jelenti, hogy a logikai üzleti egységek (aldomainjeink), amelyek függetlenített interfészeket javasolnak – nem valósulnak meg a kódban, ami zavart és növekvő összetettséget eredményez az évek múlásával.

a nagy ötlet: Szervezze Rails kódot modulok üzleti aldomain

annak ellenére, hogy a Ruby osztályok az alkalmazás valószínűleg él a globális névtér, akkor könnyen Pengetős modulok. Célunk, hogy olyan logikai tartománykódcsoportokat hozzunk létre, amelyek elkülöníthetők önálló komponensekké.

valójában a tartományvezérelt tervek egyik célja, hogy egy-egy leképezés legyen egy Aldomainről egy korlátozott kontextusra.

OK, mit jelent ez? Vegyünk néhány ajánlást, példákkal együtt.

mappastruktúrák invertálása lapos tartományorientált csoportosításba

emlékeztethet arra, hogy a Rails konvenciók követése olyan mappahierarchiákhoz vezet, amelyek az osztályokat szerepek szerint csoportosítják:

helyezzünk át mindent egy új könyvtárstruktúrába: csoportosítsuk inkább a funkcionalitást domain szerint. Kezdjük az első variációval, amelyet lapos domain-orientált csoportosításnak nevezek.

osztályok modulálása

ezután az osztályokat modulálni kell attól, ami korábban volt. Mivel az Illesztőprogram osztály a telekocsi tartomány alá tartozik, hozzáadjuk egy Telekocsi modulhoz:

ezt minden osztálynál meg kell tennie, amelyet a app/domains lapos könyvtárszerkezetbe helyez.

kapcsolódó modellek hivatkozása teljes osztálynév szerint

ezenkívül módosítania kell az ActiveRecord modell társításait, hogy az osztályra teljes, Modulált elérési útja alapján hivatkozzon:

Tartsa naprakészen a vezérlőket arról, hogy hol találhatók az újonnan Modulált nézetek

ezt a kis bitet is be kell illesztenie, hogy a vezérlő útvonalai tudják, hol keressék a nézeteket:

itt van a jó dolog: nem kell egyszerre mozgatnia az összes kódot. Kiválaszthat egy kis domaint az alkalmazásában, a kód legérettebb területét vagy azt a területet, amelyet a legjobban megért, és elkezdheti áthelyezni aggályait egyetlen domain mappába, miközben a meglévő kódot nyugalomban hagyja, amíg készen áll a mozgásra.

most tettünk néhány apró lépést az építészeti tisztaság elérése érdekében alkalmazásunkban. Ha most megnézzük, moduláris mappastruktúráink segítettek nekünk a kódunk ilyen csoportosításában:

a motorháztető alatt alkalmazásunk inkább így néz ki:

mi működik jól ezzel a megközelítéssel?

1. kevesebb zaj van minden fájlkönyvtárban – a fájlok tartomány-specifitás szerinti csoportosításával természetes szervezeti pontot találunk
2. az egyes tartománymappákban maradt entitások nagyon összetartóak – valószínűleg természetesen kommunikálnak egymással, és természetesen megjelennek egymással
3. azok az entitások, amelyek nem tartoznak egymáshoz, most elkülönülnek (lazább összekapcsolt)
4. ha az egyes tartományok mappájában található csapatok, hogy a munka mellett aldomain-felelősségek, ezek a mérnökök most működhet egy áramvonalasabb, elszigetelt módon. A lazább csatolás lehetővé teszi ezeknek a csapatoknak, hogy bizalommal végezzenek változtatásokat, hogy nem vezetnek be regressziókat vagy egyesítik a konfliktusokat a kódbázisba
5. a szakasz hosszú távon be van állítva, hogy elkezdje mozgatni ezeket a tartománymappákat egy független szoftverszolgáltatásba (erről bővebben egy jövőbeli blogbejegyzésben)

ha további útmutatást szeretne kapni ebben a mappastruktúrában, kifejlesztettem egy mintaalkalmazást, amely bemutatja ezt a tartomány-orientált mappastruktúrát: http://github.com/andrewhao/delorean. Nézze meg, és mondja el, mit gondol.

mit tanultunk?

együtt töltött időnkben megismertük a domainek és aldomainek körüli domain-vezérelt tervezési koncepciókat. Megtanultuk, hogyan vizualizáljuk szoftverrendszereinket Korlátozott kontextusként egy kontextus térképen, amely megmutatta nekünk a rendszer azon területeit, amelyek koherens részekként tartoznak egymáshoz.

egy gyakorlati megjegyzés végén bemutattuk, hogyan lehet a Rails fájlokat és mappákat “megfordítani”, és újragondolni domain-első csoportosításként.

a következő bejegyzésemben folytatjuk a vitát egy közelgő blogbejegyzésben arról, hogyan lehet tovább szétválasztani a domain-orientált Rails kódot a domain eseményekkel, és végül eljuthatunk a mikroszolgáltatások földjére.