Blog Alexander byndyu domén-vezérelt tervezés domén létrehozása

Ennek egyik eleme a sikeres alkalmazás -, hogy hozzon létre egy olyan domain a legjobban illik a forgatókönyv a rendszer.

Vérszegény tartomány modell

Ha a domain tárgyak adatokat tárolják, és mindent, ami azokban van, ez a tulajdonság lehet / készlet. akkor használja a vérszegény domén modellben. A jellemző az, hogy a domain objektum nem folytat.

használat módja, például egy online áruház:

1. A felhasználó, aki bejelentkezett, kap egy levelet, hivatkozva a regisztrációs visszaigazolást. Miután a link, ez megerősíti a regisztráció és adja meg felhasználónevét és jelszavát a rendszerbe.
2. A felhasználó megrendeléseket
3. Ugyanakkor a kabinet, látja a teljes összeg, amely elrendelte. A teljes összeg a jelenlegi megbízások nem veszik figyelembe a már teljesített rendelések

Kezdjük vérszegény adatmodell. Mi lesz a kategóriába tartozó:

Mind a forgatókönyv működik elég egyszerű végrehajtani:

№1 forgatókönyv. aktiválás felhasználó

№2 forgatókönyv. hozzáadása érdekében

№3 forgatókönyv. Kiszámítása a teljes összeg

A fő kérdés: hol a kód található?

Ez a legegyszerűbb és rossz megoldás. Fogjuk írni ezt a kódot közvetlenül a felvezető vagy a aspx oldalas WinForms:

Minden rendben lesz, amíg a termék adhatunk csak a forma, és számolja a teljes összeg jön csak ezt a képletet. Problémák akkor kezdődik, amikor egy másik formája lesz szükség ugyanazt a funkciót. Mi lesz megismételni a kódot. Aztán, ha megváltoztatja a logika, meg kell kijavítani az összes kód-behind'ah.

Silly másolni a kódot, majd kiad egy csomó időt, hogy rögzítse az egyik a megváltozott üzleti követelményeket.

Mégis, nem fogjuk megismételni. Nyújtunk be kódelhelyezési forgatókönyvek az osztályban a hangzatos név AccountHelper vagy Fiókkezelő. Valószínűleg ez az osztály a hontalan, ezért statikus.

A probléma osztály neve * Segítő * menedzser vagy hogy engedheti meg magának, hogy semmit. Elvont teszi nevek „help” a számla osztály csinálni teljesen különböző dolog. Ezek a csoportok előbb-utóbb lesz Isten-objektumot.

Ezekben az osztályokban sok hátránya. Például nehéz teszt kód, amely ezeket az osztályokat, mert a statikus. Azt, hogy a kód sokkal illeszkedésre, mert sérti az függőségi inverzió. Nagyon gyakran az egyik segítő „ami más segítő” s. Ennek eredményeként a függőség gráf hasonlít egy pókháló kapcsolatok.

Ezen túlmenően, ez a megoldás a hiányosságokat a következő.

Kezdjük is küzdenek erős összekapcsolódás a kódot. Azt csinálni, és hozzon létre egy osztályt AccountService interfész IAccountService. Minden tárgy, ami kell az aktiválás vagy hozzáadjuk a sorrendben fogja használni IAccountService felület helyett a végrehajtás. Ez abban is segít nekünk, hogy teszteljék a kódot.

Mi foglalkozott és rokonsági vizsgálat. Már egy lépést előre. De látom, két kihívással.

Típus funkciók AddOrder és CalculateOrdersSum lesz elég sokat. Fél év után a fejlődés interfész IAccountService nőnek 40-50 funkciókat. „Szennyezés” felület nem élhette túl, ha nem a második probléma.

A kód lehet bárhol a szolgáltatás bypass write „azok aktiválását” felhasználó. Például, hogy a számla objektumot az adatbázisból, őt IsApproved mezőt igaz, és így felejtsd el frissíteni ActivationDate területen. Ugyanez vonatkozik a kiegészítéssel, a script sorrendben. Hívhatja az Új funkciót a tulajdonságok rendelések bárhol és felejtse el a fiók mezőbe sorrendben hozzá. Ez teszi a rendszert instabil. API alkalmazások védtelen előtt a rendszer felhasználói számára. Egy ilyen megközelítés csak remélhetjük, hogy a programozó tartja szükségesnek funkció IAccountService. és nem fogja feltalálni a megközelítést.

Tedd az összes ezeket a funkciókat a tartomány tárgy maga fiók. Figyeljük meg, hogy hogyan kell változtatni hozzáférést módosítókat területén a tárgy:

Most a alkalmazási területen lehetővé teszi a felhasználónak, hogy készen áll az API, amely nem trebudet sem Helper „s vagy szolgáltatásokat. Ezen kívül, mi biztosítja a felhasználó hibákat. Nem lesz képes aktiválni a fiók téve csak IsApproved. Most Aktiválás funkció is kitölti a szükséges mezőket.

Tehát, ha a funkció működik adatok és tárgyak, amelyek a tartományon belül, akkor valószínű, hogy el kell hagynia ezt a funkciót a tartományon belül. Amellett, hogy a megbízhatóság a kódot, akkor hozzon létre egy domain mellett a nyelv az alkalmazás.

Nos, a megoldás a számot 0 - Kényelmetlenül érzem magam, ha jól emlékszem, hogy gyakran használják azt. Ez, természetesen, egyszerűen elfogadhatatlan.

határozat száma: 1 - ez is csak a vezetékes logika és csak akkor, ha AccountHelper osztály áll (helló kapitány nyilvánvaló :)). Egy kis projekt elég tűrhető megoldás.

Megoldás No. 2 - számomra ez alkalmas. Ha az üzleti logika egy külön egységet és a script kidolgozása az üzleti logikát lehet változtatni (azaz van, vagy lehet több implementációja IAccountService), akkor miért nem. De általánosságban megfelelő lenne, hogy hozzon létre több felületek, amelyek mindegyike támogatja a konkrét műveletek a szervezetek - például IAccountViewer, IAccountActicvator (példák természetesen erőltetett, de a lényeg világos) - mindezek interfészek megvalósítása és egy osztályt az ügyfél nem fontos.

Általánosságban, a választás a tárolási helyét az egység, feldolgozó logikai: az a szervezet vagy szolgáltatás - ez egy filozófiai kérdés. Minden attól függ, a kapcsolat a domain a logika. Ha szeretné használni ezt a logikát, hogy minden felhasználó számára a domain, akkor a logika az entitás. Ha ez különösebb logika kölcsönhatás az ügyfél és a domain - úgy dönt, hogy távolítsa el a logika a szolgáltatást. Ha egy köztes változata - már megoldott alapján a józan ész.

Ezt nevezik az ISP.

PS: azt feltételezzük, a szolgáltatási szint az egyes tartományokhoz ügyfél. De ha az ügyfél használja a legtöbb módszer a meglévő szolgáltatási szint akkor használjuk ezt a szolgáltatási szintet. Nos, annak érdekében, hogy elkerüljék a párhuzamos szolgáltatások megfelelő használata a minta parancsokat.

harmadik minta a hiányosságokat általában rangsoroljuk kell szél a szállítási réteg, amely szintén fenntartásához szükséges adat redundancia, és a nagyobb, ami részben megoldott lusta betöltést.

Ha jól értem, akkor a döntés №2 kifejezés részben vérszegény modell szerint. Egyfajta kompromisszum: ez egy olyan domain technikák, mint például a activate, amelyek nem függnek a külső osztályok, bár tartalmazza a logika. A többi a nyújtott szolgáltatás a réteg.

@Constantine
Köszönöm a komplement, nagyon értékes.

Érdekes lesz, hogy nézd meg a példákat:

> Ezen felül, szemben függőségi lánc

Ha van egy csomó kód, dobja az e-mail.

És ha egy kicsit bonyolítja a példát, szeretnénk bemutatni egy új üzleti funkciók szabály: nem lehet hozzáadni a számlát a megrendelés, ha már van egy rendelés állapota IsComplete = true. Hol adni ezt a tesztet? Nyilvánvaló, hogy a AddOrder Account osztály módszer, mert ez felelős a hozzá mi annak érdekében, hogy a számla.
De ebben az esetben mi ellenőrzést követően pozitív volt, de még mielőtt a megrendelés került - egy másik felhasználó hozzá egyéni állapot IsComplete = true, akkor a check már elmúlt, a sorrendben az első felhasználó lesz csendben hozzá, és a szabály van törve szabályokat. Természetesen meg kell adni, és ellenőrizze a tranzakció történik az adatbázisban, de az adatbázis-tranzakció - nem ez a tartomány réteg.
Hogyan juthat ki ez a helyzet?

Itt az alkalmazástól függ a terhelés.

A legegyszerűbb lehetőség, hogy a Lock ezen a ponton.

Egy másik lehetőség, ha megnyit egy tranzakciót adja izolációs szint, amely nem teszi lehetővé egy ilyen helyzetben.

Mit már próbálta megoldani a problémát?

NHibernate nem használja, de az ötlet megvalósult.

Miért csak a „tranzakció kezelés végzik a vezérlő szintű objektum UnitOfWork”? Itt egy példa a megrendelések és számlák, mert valójában az a kötelezettség, hogy ellenőrizze a szabály, hogy nincs figyelembe lezárt megrendelések - a feladata a robbanás terület. És logikus, hogy tegye, hogy ellenőrizze a módszerrel számolva AddOrder, feltámasztva a tranzakciós UOW. Ha hozzá ezt a felelősséget a vezérlő kiderül, ő már tudni, hogy a AddOrder módszer. Ha a vezérlő szemben önmagában csekkek - ez azt jelenti, hogy a szint a működési logikáját foglalkozik tárgyát logika.

> És logikus, hogy tegye, hogy ellenőrizze a módszerrel számolva AddOrder, feltámasztva a tranzakciós UOW

Ellenőrizze és AddOrder és UOW jön létre a vezérlő. Ezek egymás nem fogja tudni.

Valószínűleg nem értem a kérdést, mert nem fog tudni UOW, ha UOW fogják hívni ezt a módszert. Ha a módszer hívás maga a kontroller kell kiszabni UOW, azt feltételezzük, hogy a hívó fél képviselje, mi folyik belül a módszer, hogy egy ok arra, hogy rákényszerítse hívás UOW.

UOW létre az a tartományban objektum nem utal UOW. Például, client.Lock () módszer megváltoztatja a állapota az objektum. Megváltoztatása ezeket az adatokat UOW pályák automatikusan. Ez képes megtenni, például NHibernate.

hmm. és komenty miért dörzsölje.

Köszönöm a válaszokat, de. Rájöttem persze, hogy nehezen kivitelezhető DDD a tömegeket, de ha jön, azt kérte, hogy nem hivatkozhat a konkrét megvalósítására a választ (mellesleg már említettem, hogy nem használja NHibernate), ez legyen egy közös sablonok és megközelítések. A válasz a lélek „és a NHibernate képes” - nem tekinthető =)

UOW keletkezik a vezérlő egység szinten UOW vett és helyezzük vissza a UOW. Plusz UOW pályák változtatásokat szervezetek. Igen, ez már megvalósult sok a ORM, de lehet, hogy nézi az elmélet, írd meg megvalósítása.

Jó napot kívánok. Van nebolshry kérdés félreértés. Poluchaetsya design (write) az objektum modell oblátusok (DDD). majd csatlakozik a NHibernate térképezés?

Igen, ez így van. És a leképezés van szükség, csak ha az adatbázis nem kell azonnal. A fejlesztés megkezdése érdekében, akkor használja az adatbázist a memóriában, vagy szöveges fájlokat. Mapping a következő lépés.

Helló Szeretjük ezt: Van DataAccess összeállítás-konfiguráció, térképezés, stb (Használata NHibernate); Vannak szerelvény DomainModel. DA van egy link a DM. A kérdés: mi köze a logika, amely előírja, hogy minden adatot az adatbázisból? Nem tudom a funkciók a domain objektum használni ORM. Meg kell teremtenünk 3uyu összeszerelési szolgáltatások, de ez nem gud (csak mi kaptuk a fent említett a cikkben). Mit kell tenni?

Az a tény, hogy hozzon létre egy külön réteget manipulálni tárgyakat - ez normális, vagy nem működik. Egyszerűen, akkor szolgáltatásokat mind a tíz technikákat és lehet parancsot (Command minta), ahol minden csapat feladata lesz a részesedése a logika.

Alexander, ez lehetséges, és jogot, hogy a domain tárgyakat a kód első megközelítés az EF? És ha ez kezdetben vérszegény tartomány tárgyak később refactor őket megfelelően a „határozat 3” (add az API és módosíthatja a hozzáférési módosítók a alkotóinak)?
És még egy kérdés:
„Az olyan funkciók, AddOrder és CalculateOrdersSum lesz elég sokat. Fél év után a fejlődés interfész IAccountService nőnek 40-50 funkciókat.” Általában hasznos lehet például IAccountService felületek, és hol?

Denis, akkor, mert nincs korlátozás. Van projektek EF, ott voltunk egész ideje alatt használatra.

„Lehet bármilyen hasznos felületek, mint IAccountService és hol?”

Cikk, persze, több mint egy éve. De remélem a választ. Tehát, oké, a account.AddOrder, account.Activate stb Mindent általában, ez érthető. A rendelés például is van néhány order.AddProduct, order.Approve stb És mégis mi a termékeket is, amelyek számos különböző tulajdonságokkal (cikk, cím shortTitle, url, leírás, jellemzők []). A menedzser / operátor képes szerkeszteni mindegyiket, és hogyan lehet létrehozni ilyen entitások nem világos, hogy ezek nem nyilvánosak alkotóinak. productUpdate (adat) vagy azt, hogy legyen az a domain?

Tegyük fel keretében megalakult a rend számunkra nem fontos. Akkor tegye két entitás ProductForOrderContext és ProductForEditingContext? Ebben az esetben a szervezetek száma jelentősen razrostatatsya, és a második esetben, a „lényeg” ismét lesz vérszegény, sőt még egy DTO. Általánosságban elmondható, hogy nem egyértelmű.

„A második - alakítás domén és a nyelv nem probléma.”

Ez még egy probléma, még egy pár:

§ Meg lehet keverni a halom logika például - a vendég, aki regisztrálja a felhasználó priveligirovanogo felhasználói adminisztrátor.

§ Az osztály végül is Isten-object-én.

§ SZILÁRD elve sérül.
Nevezetesen S - az egyes osztályokra kell
Ez van hozzárendelve egyetlen kötelessége.