Már több, mint két éve, hogy megismerkedtem a Domain Driven Design-nal (DDD), azóta is projekten alkalmazzuk munkatársaimmal a filozófiát. Úgy döntöttem, hogy egy cikksorozatot indítok ebben a témában. A cikksorozat célja a filozófia népszerűsítése.
Mi is ez?
A filozófia lényege az üzleti probléma orientált megközelítés. A filozófia alkalmazása szoftverfejlesztési projekt esetében a következőket fogja eredményezni:
-
megismerjük az adott üzleti területet, amelyhez a szoftvert készítjük,
- a teljes fejlesztői, tesztelői csapat megismeri az üzleti területet,
-
elsajátítunk és kialakítunk egy mindent átható nyelvet (Ubiquitous Language), amely a teljes projekt kommunikációját megalapozza, ezáltal:
- az ügyféllel egy közös nyelvet fogunk beszélni,
- a teljes fejlesztői, tesztelői csapat is ezt a nyelvet fogja használni,
- a nyelvet nem csak szóban, hanem írásban is alkalmazzuk a forráskódban és a dokumentációkban,
- és végül: minőségi szoftver készül el.
Ha tényleg minőségi szoftvert szeretnénk készíteni, értenünk kell ahhoz az üzleti területhez, amit a szoftverrel támogatni kívánunk. Véget ért az az idő, amikor a fejlesztők magányosan meghúzódva a specifikációk alapján a boxaikban kódoltak. A teljes fejlesztői, tesztelői csapatnak meg kell értenie, mi az, amit csinál, és hogy hogyan gondolkozik az ügyfél.
Mitől új?
Egyrészt nem új, mert eddig is voltak olyanok, akik évtizedek ezelőtt úgy fejlesztettek szoftvert, hogy ezeket az elveket ismerték. Azért sem új, mert különféle megközelítésekből is erre a következtetésre lehet jutni. Gondoljunk a Scrum-ra, ahol minden sprint közben azon dolgozunk, hogy az ügyfél elégedettségét a demón kivívjuk, vagy gondoljunk az XP-ben az on-site customer szerepkörre. Arról nem is beszélve, hogy az agilis megközelítéseknek mind az ügyfélcentrikusság az alapja.
Másrészt azért új a filozófia, mert Eric Evans megírta a bibliát. (A könyv elég hosszú, 500+ oldal, készült belőle egy ingyenesen letölthető kivonat.) A 2004-ben megjelent könyv tudatosan rendszerezi mindazokat az ismereteket, amiket Eric a szoftverfejlesztési projektekben ezzel a hozzáállással megtapasztalt. A rendszer magja a Domain Model, amelynek feladata, hogy a komplex üzleti tudást és a leendő szoftver működését, ismereteit hatékonyan (értsd: jól érthetően) rendszerezze. A Domain Model-t sokféleképpen lehet kommunikálni, de elsődleges megjelenési formája maga a forráskód.
A Domain Model
A könyv utal arra, hogy hibás a hagyományos vízesés modellben lefolytatott projektek megvalósítása:
- Követelményeket gyűjtögetünk, ezt leírjuk egy többszáz – ne adj, Isten – több ezer oldalas doksiban. (Ki fogja ezt elolvasni és megérteni? Mi garantálja, hogy jó lesz ez az anyag?);
- A “nagy” szoftvertervezők összepattintják a szoftver modelljét, terveit (újabb pár száz oldalas doksi, telepakolva mindenféle UML-diagramokkal; vagy esetleg valamilyen MDA tool-lal készített szörnyeteg, amiből már le is lehet generálni a forráskódot, és ebbe a “niggerek”-nek már csak be kell írnia a kódot);
- Az elkészített tervek alapján a fejlesztők elvégzik a munkát;
- Ha a fejlesztők végeztek, a tesztelők tesztelnek, megtörténnek a hibajavítások;
- …és KÉSZ.
Ez a fajta hozzáállás egyirányú kommunikációt eredményez. Valaki leírja a követelményspecifikációt, ezt a terméket átadja a tervezői csapatnak, a tervezői csapat pedig a terveket adja át a fejlesztői csapatnak (pl. logikai rendszerterv), akik végül a szoftvert a tesztelői csapatnak nyújtják át. Elég sokan rájöttek már arra (de sokan még mindig sötétségben élnek), hogy ez szinte soha nem működik, de legalábbis nem eredményez minőségi szoftvert. (Viszont kiválóan védheti vele mindenki a saját s***ét.)
A fejlesztőknek és az üzleti megrendelőnek folyamatosan együtt kell működnie. Nincs szükség áttétekre, közbülső szereplőkre. Nem kell olyan, aki több száz oldalas doksikat gyárt. Ezek helyett az emberek helyett inkább bízzuk a tehetséges fejlesztői csapatra a megvalósítást.
Sokkal előnyösebb az a megközelítés, hogy a rendszer modelljét már egyből a forráskódban megvalósítjuk, és van üzleti szakértőnk, aki segít abban, hogy a modellel kapcsolatos – folyamatosan felmerülő – kérdésekre választ kapjunk. Az üzleti szakértő valóban ért a problémához, rendszerint ő maga az ügyfél.
A DDD-vel végrehajtott projektek során a Domain Model folyamatosan fejlődik (ahogy a fejlesztők dolgoznak rajta), átalakul, áttöréseken esik át, és újabb szinteket ér el az üzleti megismerésnek és a megvalósításnak a folyamatában. A Domain Model egy az egyben tükrözi a fejlesztői csapat tudását az adott üzleti területről.
A Domain Model folyamatos evolúciójának létjogosultsága a következő problémák miatt indokolt:
- a követelmények állandóan változnak: az ügyfél nem tudja előre megmondani, hogy pontosan mit szeretne,
-
(általában) nincs az az agy, aki egy rendszert előre meg tudna tervezni, mert:
- túl komplex,
- az ördög mindig a részletekben rejlik: problémák hada implementáció közben jön ki (technológiai és üzleti problémák), ezek visszahatnak a már meglévő elképzelésekre, tervekre, a kódbázisra;
- a felmerülő üzleti problémákra tudnunk kell a válaszokat ahhoz, hogy tovább léphessünk. Ezeket a problémákat a projekt elején nem is lehet látni, és csak a szoftverben folyamatosan fejlődő modellben jelentkeznek.
Mikor alkalmazzuk a DDD-t? Hogyan csináljuk?
(folyt.köv.)
tatabánya
Jul 28th, 2011részben idevág a spanyolt ms srácok ddd-hez kapcsolódó tech könyve (v1-et pl. Ayende is lehúzta, a v2 viszont kiválóz alapozó és összegző mű):
http://microsoftnlayerapp.codeplex.com/
abu
Apr 28th, 2014Ha esetleg valaki nem akarja az 500+ ost elolvasni, itt egy ingyenes megoldás röviden. Meg is lehet venni 30$ ért ha esetleg támogató kedvünkben vagyunk.
http://www.infoq.com/minibooks/domain-driven-design-quickly
Marhefka István
May 7th, 2014Azóta már sokat változott a DDD implementációs része. Előtérbe kerültek az aggregate-ek és a domain eventek (ez utóbbiakról egyáltalán nem is szól az eredeti könyv). A domain modell jelentősége is csökkent.
A múltkor szóba került, hogy mi is az a DDD, mi a magja? Én az elmúlt 6-7 év távlatából azt tudom mondani, hogy a DDD lényege, hogy a business domain és a kód között minél kevesebb legyen az “átforgatás”, minél jobban legyen közvetlenül megfeleltethető a kettő egymásnak. Tárjuk fel az üzleti fogalmi rendszert, pontosítsunk a szakzsargont, és ezt jelenítsük meg a kódban is és hassunk vissza az eredeti nyelvezetre is. Implementációs oldalról pedig a tanulság annyi, hogy az üzleti fogalmi rendszert és logikát egy önálló POJO modellben valósítsuk meg, ami lehetőleg mentes a technológiai infrastruktúra részleteitől. Ezzel a megközelítéssel a komplexitás viszonylag jól kezelhető. Feltéve persze, hogy annak a problémának a súlypontja, amire megoldást szeretnénk adni, az üzleti logikánál/fogalmi rendszernél található, nem pedig a technológiánál.