Domain Driven Design 1. rész - mi ez?

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.)

[Update: A cikk második része megtekinhető itt.]