Wstęp

Całkiem nie­daw­no pisa­łem o two­rze­niu dia­gra­mów klas a kon­kret­nie mode­lu dzie­dzi­ny w odpo­wie­dzi na post pew­ne­go blo­ge­ra. Wymiana poglą­dów skoń­czy­ła się ze stro­ny adwer­sa­rza na zwró­ce­niu uwa­gi, iż dia­gram klas może poka­zy­wać wię­cej niż mój (bo może) ja zaś zwró­ci­łem uwa­gę na fakt, że dia­gram klas to nie jakiś model a model powi­nien mode­lo­wać jed­ne coś. Pokazanie na jed­nym dia­gra­mie klas dużo raczej mija się z celem, bo moż­na zabrnąć w rejon gdzie spraw­dza się rekla­ma Banki od wszyst­kie­go są do nicze­go. Tak więc nie nale­ży prze­cią­żać diagramów. 

Model dziedziny systemu to model mechanizmu jego działania

The Domain Model is an object model of the doma­in that incor­po­ra­tes both beha­vior and data. [Model Dziedziny jest obiek­to­wym mode­lem dzie­dzi­ny, któ­ry zawie­ra zarów­no zacho­wa­nie jak i dane.]

https://​java​-design​-pat​terns​.com/​p​a​t​t​e​r​n​s​/​d​o​m​a​i​n​-​m​o​d​el/

Tak więc for­su­ję tezę, że dia­gram klas to albo model poję­cio­wy (związ­ki tak­so­no­micz­ne i pre­dy­ka­ty mię­dzy nazwa­mi sto­so­wa­ny­mi w danej dzie­dzi­nie) albo model dzie­dzi­ny czy­li mecha­nizm opi­su­ją­cy dane biz­ne­so­we i meto­dy ich prze­twa­rza­nia. W tym dru­gim przy­pad­ku jest to Model z wzor­ca MVC, a Model ten moż­na stwo­rzyć sto­su­jąc np. wzor­ce DDD. 

Model nie powi­nien być anemiczny:

Jednym z naj­częst­szych powo­dów powsta­wa­nia ane­micz­nych mode­li dome­no­wych jest spo­sób pro­jek­to­wa­nia apli­ka­cji w opar­ciu o wcze­śniej stwo­rzo­ny sche­mat bazy danych. To pro­wa­dzi to do tego, że model dome­no­wy powsta­je w sku­tek mapo­wa­nia tabel do klas posia­da­ją­cych odzwier­cie­dlo­ne kolum­ny w posta­ci wła­ści­wo­ści. Jedynym wyzwa­niem dla nie­któ­rych osób może być mode­lo­wa­nie rela­cji, któ­re w przy­pad­ku bazy danych są klu­cza­mi obcy­mi, zaś w przy­pad­ku obiek­to­we­go mode­lu powin­ny być rela­cja­mi do innych obiek­tów. Nie bra­ku­je oczy­wi­ście przy­kła­dów, gdzie rela­cje w mode­lu dome­no­wym two­rzo­ne są rów­nież w opar­ciu o klu­cze obce, co cał­ko­wi­cie zaprze­cza obiek­to­we­mu pro­gra­mo­wa­niu (źr. za pomo­cą Domain Model ? !FrAgile Thinking.)

Zwrócę tu uwa­gę na waż­ną rzecz: w mode­lach obiek­to­wych sys­te­mów pod­sta­wo­wym związ­kiem (w j. ang. rela­tion) jest zwią­zek uży­cia, jest to wywo­ła­nie ope­ra­cji obiek­tu: w mode­lach obiek­to­wych obiek­ty sie komu­ni­ku­ją (wymie­nia­ją komu­ni­ka­ty), nie są to żad­ne trwa­le powią­za­ne byty. 

Polecam cały powyż­szy arty­kuł (no ja pomi­ja­łem część zwią­za­ną z kodem bo już nie pro­gra­mu­ję ;). Polecam przy oka­zji arty­kuł: http://​msdn​.micro​soft​.com/​e​n​-​u​s​/​m​a​g​a​z​i​n​e​/​d​d​4​1​9​6​5​4​.​a​spx.

Patrz tak­że Anemiczny Model Dziedziny jako antyw­zo­rzec obiek­to­wy.