Насоки за решаване кога ролята на домейн трябва да бъде изрично моделирана

Търся някои насоки за това кога човек трябва изрично да моделира роля в модела на домейна.

Ще обясня настоящата си позиция с помощта на пример тук.

Да кажем, че изграждаме система за здравеопазване и изискванията на бизнеса гласят

„Че само лекари с над 3 години опит и определена квалификация могат да извършват операции“

В този случай е очевидно, че действието по извършване на операция може да бъде извършено само от лице, което играе ролята на лекар и лекарят трябва да отговаря на определени предпоставки, за да извърши действието

docter.performSurgery()

Така че по принцип всички лекари не са еднакви

Този метод вероятно ще провери дали предварителните условия са изпълнени

Така че в горните случаи ще моделирам изрично ролята.

Сега нека разгледаме алтернативния сценарий.

Само администратор може да одобри превод на средства

В горния случай не намирам необходимост да моделирам тази роля в домейна, тъй като няма правила, които да разграничават един администратор от друг в моя домейн.

Всяко лице/потребител с разрешение на администратор може да извърши това действие, предпочитам да проектирам това в моята инфраструктура за сигурност и да гарантирам, че

approveTransfer() методът, извикан на приложния слой, се извиква само ако влезлият в момента потребител има разрешението ADMIN.

Така че "моделът на домейн", под който имам предвид класове като класа на акаунта, не познава това правило, това е кодирано в приложния слой или чрез AOP, или вероятно чрез класа AccountService или други подобни.

Какво казват мъдреците за това? :)


domain-driven-design
person Sudarshan    schedule 18.10.2014    source източник
comment
По отношение на използвания език и извинение за следното, тъй като не знам как са структурирани агрегатите, но не би ли било doctor.scheduleSurgery(date)? От вашата публикация и функция performSurgery звучи така, сякаш системата извършва рязане!   -  person morleyc    schedule 19.10.2014
comment
Съгласен съм, бихме могли да обсъдим използвания език, тъй като не е от конкретен случай на употреба, но фокусът на въпроса беше върху това кога класът лекар (роля на домейн) трябва да бъде моделиран и кога не,   -  person Sudarshan    schedule 21.10.2014

Отговори (1)


arrow_upward
0
arrow_downward

Когато проектирам агрегати, винаги си задавам важен въпрос.

  • Каква е границата на последователност за процеса, който се опитвам да моделирам?

Питам какви правила трябва да се прилагат по време на всяка една атомна операция. Това се нарича транзакционна граница и това е вашето масло за хляб, когато дефинирате вашите инварианти (правила, които винаги трябва да са верни по време на живота на атомарна операция - от началото до края).

Както го виждам, правилото, че лекар/хирург трябва да има n години опит - за конкретна операция - е инвариант, който винаги трябва да е последователен в транзакциите (като например при извършване на операция). Поради това трябва да се моделира като транзакционна граница в рамките на един агрегат.

Тъй като агрегатите могат да гарантират последователността само в себе си, инвариантите, за които отговарят, не трябва да изтичат извън него. По мое мнение и ако приемем, че лекарят е съвкупност, отделен ролеви модел не трябва да носи отговорност за инвариант, за който трябва да отговаря самият модел на лекаря.

Връзките агрегат към агрегат наистина трябва да се установяват само за да осигурят „помощ“ при предоставянето на липсваща част от информацията. Но правилата и начинът, по който тази информация се тълкува, трябва да бъдат изолирани в рамките на съответната съвкупност.

Отделна ситуация може да възникне при удостоверяване на потребителя. Може да имате ограничен контекст с Customer модел, но подробностите за разрешенията, удостоверяването и ролите са толкова обширни, че изискват напълно отделна система, с която да се справите. В този случай може да създадете отделен ограничен контекст за User Roles and Permission и да свържете двата ограничени контекста. В този сценарий може да имате услуга за домейн, която се занимава с комуникацията между двете. Обадете се на Customer root с операция и предайте услугата на домейн за някакво намерение, разкриващо двойно изпращане, и оставете услугата на домейн да реши дали тази операция преминава или не. В този сценарий обаче отговорностите на потребителското удостоверяване изобщо не са Customer. На Customer просто не му пука (защото не може сам да гарантира транзакцията) и зависи от User Auth and Roles да реши какво да прави.

От: Implementing Domain Driven Design - Vaughn Vernon

Правилно проектиран агрегат е този, който може да бъде модифициран по всякакъв начин, изискван от бизнеса, като неговите инварианти са напълно съгласувани в рамките на една транзакция. И правилно проектираният ограничен контекст променя само един агрегатен екземпляр на транзакция във всички случаи. Нещо повече, не можем да разсъждаваме правилно върху агрегатния дизайн без прилагане на транзакционен анализ.

person Seph    schedule 28.04.2015