A tartományvezérelt tervezés (ritkábban tartományvezérelt tervezés , DDD) olyan elvek és sémák összessége, amelyek célja az optimális objektumrendszerek létrehozása. Ennek lényege a tartománymodelleknek nevezett szoftverabsztrakciók létrehozása . Ezek a modellek olyan üzleti logikát tartalmaznak , amely kapcsolatot hoz létre a termék alkalmazási területének tényleges feltételei és a kód között.
A tartományvezérelt tervezés nem egy speciális technológia vagy módszertan. A DDD egy olyan szabálykészlet, amely lehetővé teszi a megfelelő tervezési döntések meghozatalát. Ez a megközelítés lehetővé teszi, hogy jelentősen felgyorsítsa a szoftvertervezés folyamatát egy ismeretlen témakörben.
A DDD megközelítés különösen hasznos olyan helyzetekben, amikor a fejlesztő nem szakértő a fejlesztés alatt álló termék területén. Például: egy programozó nem ismerheti az összes olyan területet, ahol szoftvert kell készíteni , de a struktúra megfelelő ábrázolásával, tartományorientált megközelítéssel könnyen meg tud tervezni egy alkalmazást a kulcspontok és a munkaterület ismerete alapján. .
Ezt a kifejezést először E. Evans vezette be azonos című, "Domain-Driven Design" [1] című könyvében .
Ideális esetben a tervezés során egyetlen modellt szeretne, amely teljes mértékben leírja a teljes témakört, de a valóságban a termékfejlesztési folyamat egyszerűsítése érdekében a tartomány több egymással összefüggő modell kombinációjaként jelenik meg.
Az alkalmazás architektúra diagramja egy vagy több tartománymodell leírása, és ezek egymáshoz való viszonya.
Több modell használata a projekt különböző szintjein . Ezt a megközelítést a modellek közötti különféle kapcsolatok csökkentésére használják, ami kiküszöböli a kód bonyolultságát és bonyolultságát . Néha nem világos, hogy a modellt milyen összefüggésben kell használni.
Megoldás: Határozza meg pontosan azt a kontextust, amelyben a modellt használja. Határozza meg e modell használatának és jellemzőinek határait!
Amikor nagyszámú ember dolgozik egy projekten, hajlamos a modell több kisebb részre osztani. Minél több ember, annál jelentősebb ez a probléma. Végül a projekt integritása elvész.
Megoldás: A különböző fejlesztőktől származó kódrészletek folyamatos kombinálása és a működőképesség ellenőrzése teszteléssel . Ez lehetővé teszi, hogy minden fejlesztő egyetlen nagy koncepcióban maradjon.
Ha egy nagy csoportban több különálló modellen dolgozik, előfordulhat, hogy a csapat különböző tagjai nincsenek tisztában más modellek entitásaival, ami megnehezíti a végtermék összeszerelési folyamatát.
Megoldás: A tervezési szakaszban pontosan határozza meg, hogy az egyes modellek mit csinálnak, és hogyan viszonyulnak más modellekhez. A végén egy modellkapcsolati térképet kell készítenie.
A tartományorientált megközelítésen alapuló tervezés során a következő fogalmakat használjuk:
A legtöbb vállalati rendszer nagy léptékű felelősségi területeket használ. A DDD-ben ezt a legmagasabb szintű szervezettséget korlátos kontextusnak nevezik. Például egy nagy távközlési vállalat számlázási rendszere a következő kulcselemekkel rendelkezhet:
A fenti elemek mindegyikét egyetlen, megszakítás nélküli rendszerbe kell foglalni. Tervezéskor az értesítési rendszer és a biztonsági rendszer, mint teljesen más dolog kiemelkedik. Azok a rendszerek, amelyekben a megvalósítás nem képes szétválasztani és elkülöníteni a korlátozott kontextusokat, gyakran olyan építészeti stílust kapnak , amelyet 1999-ben Brian Foot és Joseph Yoder találóan " Nagy sárlabda "-nak nevez. [2]
A tartomány-specifikus tervezés lényege a kontextusok sajátos meghatározása és az azokon belüli modellezés korlátozása.
Az entitások kifejezésének legegyszerűbb módja a főnevek : emberek, helyek, termékek stb. Az entitásoknak személyiségük és életciklusuk is van. A tervezés idején az entitásokra inkább viselkedési egységeknek kell tekinteni, nem pedig adategységeknek. Leggyakrabban a modellhez hozzáadni kívánt műveleteket valamilyen entitásnak meg kell kapnia, vagy egy új entitás létrehozása vagy lekérése kezdődik meg. A lazábban csatolt kódban sok olyan segédprogram vagy vezérlőosztály található, amelyek kívülről ellenőrzik az entitásokat .
Az értékobjektum egy olyan tulajdonság, amely fontos a modellezett tartományban . Az entitásokkal ellentétben ezeknek nincs megnevezésük; egyszerűen leírják azokat a konkrét entitásokat, amelyek már rendelkeznek megjelöléssel. Az értékobjektumok hasznossága abban rejlik, hogy sokkal elegánsabban és szándékosabban írják le az entitások tulajdonságait. Mindig érdemes megjegyezni, hogy egy objektum értéke soha nem változik a teljes programkód végrehajtása során . A létrehozást követően nem lehet módosítani.
Az aggregátum egy speciális entitás, amelyhez közvetlenül hozzáférnek a fogyasztók. Az aggregátumok használata lehetővé teszi a modellt alkotó objektumok túlzott összekapcsolódásának elkerülését. Ez elkerüli a zavart és leegyszerűsíti a szerkezetet, mert nem teszi lehetővé szorosan összekapcsolt rendszerek létrehozását.
Néha olyan műveletek vagy folyamatok vannak egy tartományban , amelyeknek nincs kijelölése vagy életciklusa. A tartományi szolgáltatások eszközt biztosítanak ezen fogalmak modellezésére. Állapot nélküliek és erősen csatoltak, gyakran egyetlen nyilvános módszert biztosítanak, és néha túlterhelést biztosítanak a beállított műveletekhez. Ha egy viselkedés több függőséget is tartalmaz, és nincs mód arra, hogy megfelelő helyet találjon az entitásban a viselkedés tárolására, akkor a rendszer egy szolgáltatást használ. Maga a „szolgáltatás” kifejezés ugyan túlterhelt a fejlesztő világban sokféle jelentéssel, de ebben a témában egy kis osztályt jelent, amely nem egy adott személyt, helyet vagy dolgot képvisel a tervezett alkalmazásban, hanem valamilyen folyamatot tartalmaz. . A szolgáltatások használata lehetővé teszi a többrétegű architektúra belépését , valamint több modell integrálását, ami az infrastruktúrától való függőséget okoz. [3]
Bár koncepcióban a tartomány-orientált tervezés nem korlátozódhat semmilyen reprezentációra, a gyakorlatban azonban az objektum-orientált programozás erősségeit használják ki . Ez az öröklődés , a beágyazás , a reprezentáció használata metódusként és osztályként. Nem szabad megfeledkezni arról, hogy a tartomány-specifikus megközelítés nem csak az OOP nyelvekre, mint például a Java , C# vagy C++ , hanem olyan funkcionális nyelvekre is alkalmazható, mint az F# , Erlang . Különösen hasznosak azok a nyelvek, amelyek támogatják saját domain-specifikus nyelveik létrehozását és használatát , mint például a Scala (lásd még: LOP ).
| Szoftverfejlesztés | |
|---|---|
| Folyamat | |
| Magas szintű koncepciók | |
| Útvonalak |
|
Fejlesztési módszertanok | |
| Modellek |
|
| Figyelemre méltó alakok |
|