Domain Driven Design UML Stereotypes – rozszerzenie w narzędziach Microsoft

Niedawno pisa­łem, że lubię i pole­cam styl DDD . Dlaczego? Bo nawet jak nie zna­my przy­szłych zmian (nowych wyma­gań) to na pew­no pro­jekt będzie się dało roz­bu­do­wać zamiast zmie­niać. Dlaczego? Bo jeśli pro­jekt dobrze ?mode­lu­je? rze­czy­wi­stość to zna­czy, że jeśli tyl­ko coś zmie­ni się w tej rze­czy­wi­sto­ści, to będzie to moż­li­we do takie­go same­go odwzo­ro­wa­nia w pro­jek­cie (Domain-Driven Design ? nie meto­da a styl?.).

Można o tym tak­że prze­czy­tać na blo­gu MSDN:

Domain Driven Design (DDD) is espe­cial­ly suita­ble for cre­ating long-term LOB Apps, but usu­al­ly, DDD is pre­sen­ted as a very pat­terns & archi­tec­tu­re rela­ted sub­ject (topics like Bounded-Contexts, Domain-Models, pat­terns like Repository, Aggregate, Value-Object, etc.), like we actu­al­ly did in our ?DDD Patterns Guidance with .NET?, but tho­se are not, in fact, the most impor­tant topics when real­ly apply­ing DDD. (MSDN Blogs).

O powo­li, ale rosną­cej, popu­lar­no­ści wzor­ca DDD niech świad­czy wspo­mnia­ne w powyż­szym arty­ku­le ​„ofi­cjal­ne” jego wpro­wa­dze­nie w posta­ci pro­fi­lu UML dla Visual Studio 11:

This exten­sion adds a UML pro­fi­le cal­led DDDProfile, con­ta­ining the fol­lo­wing ste­reo­ty­pes which can be applied to clas­ses, com­po­nents and interfaces:

aggre­ga­te

enti­ty

valueObject

repo­si­to­ry

domainService

applicationService

infrastructureService

[…] You sho­uld now be able to select the­se ste­reo­ty­pes on any class, com­po­nent or inter­fa­ce in that pac­ka­ge. (źr. Domain Driven Design UML Stereotypes roz­sze­rze­nie).

Wnikliwi pew­nie zauwa­żą tu brak wzor­ca DDD – fac­to­ry. Nie wiem dla­cze­go pomi­nię­to go w Microsoft, zapew­ne jego rolę peł­ni tu praw­do­po­dob­nie jeden z trzech ele­men­tów Service. Traktuję to jako ​„pro­blem” seman­tycz­ny (jakie zna­cze­nia nada­je­my tym nazwom ste­reo­ty­pów) ale ​„cie­szy” mnie, że fir­ma Microsoft jaw­nie sto­su­je tego rodza­je wzor­ce i nota­cje UML już na eta­pie ana­liz i pro­jek­to­wa­nia, bo to zna­czy, że for­mal­nie dekla­ru­je uży­tek z tego typu podejścia.

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy. Faktycznie, czy­tel­ni­cy mają wie­le racji twier­dząc, że jest on dość ?bli­ski imple­men­ta­cji? (a więc zbyt szcze­gó­ło­wy). Dlatego czę­sto ?lep­szym pomy­słem? jest opis logi­ki sys­te­mu na nie­co wyż­szym pozio­mie abs­trak­cji pozo­sta­wia­jąc tym samym wię­cej swo­bo­dy deve­lo­pe­ro­wi. W takich przy­pad­kach nie raz uży­wam ogól­niej­sze­go wzor­ca BCE (Boundary, Control, Entity) do mode­lo­wa­nia logi­ki biz­ne­so­wej, któ­ry jest mniej ​„szcze­gó­ło­wy” (Wzorzec ana­li­tycz­ny Boundary Control Entity i ICONIX).

Inną cie­ka­wa propozycja:

Opublikowałem też pli­ki dla visu­al para­digm i XMI dla innych apli­ka­cji CASE, któ­re moż­na prze­stu­dio­wać i uży­wać do swo­ich celów (Dokumentacja DDD)

Źródła

Evans, E. (2003). Domain-Driven Design. Pearson Education (US).
Rademacher, F. (2017). Formalizing Domain-dri­ven Microservice Design with UML’s Profile Mechanism. https://​www​.conf​-micro​.servi​ces/​2​0​1​7​/​p​a​p​e​r​s​/​R​a​d​e​m​a​c​h​e​r​.​pdf
Słowa kluczowe: , , ,

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Sławomir Sobótka 11 grudnia 2012 Odpowiedz

    Pocieszające, że MS dostrze­ga ​„momen­tum” DDD.

    Co do zbyt­nie­go sku­pie­nia na imple­men­ta­cji… Sądzę, że model DDD nie jest zbyt bli­sko impl – jest odpowiednio.
    Jeżeli wyraź­nie roz­war­stwi­my logi­kę Aplikacją od Domenowej, to w war­stwie dome­no­wej nie poja­wia­ją się żąd­ne szcze­gó­ły fra­me­wor­ka czy plat­for­my. Model dome­no­wy prze­kła­da się 1 – 1 na nagłów­ki metod klas Building Blocks. Jeżeli nawia­sy w nagłów­kach są zbyt tech­nicz­ne to moż­na je po pro­stu pomi­nąć i myśleć o czę­ściach zda­nia: orze­cze­niu i dopełnieniu:)

    Jeżeli model jest zbyt­nio odda­lo­ny od for­my DDD to pozo­sta­wia swo­bo­dę ana­li­ty­ko­wi na prze­mil­cze­nie nie­zro­zu­mie­nia domeny:P Lukę oczy­wi­ście zasy­pu­je wów­czas deve­lo­per domy­śla­jąc się szcze­gó­łów – ale zwy­kle domy­sły nie są trafione.

    Model na pozio­mie DDD pozwa­la na: zro­zu­mie­nie kosz­tu zmia­ny – bo zmie­nia­my wspól­ny model (a nie ​„tyl­ko doda­je­my chec­ko­bo­xa na ekra­nie”) oraz uzmy­sła­wia poję­cie ​„dłu­gi tech­nicz­ne­go” – np uprasz­cza­my pew­ne czę­ści mode­lu ze świa­do­mo­ścią, że zamy­ka­my go na roz­bu­do­wę w tę stronę.

    1. Jarek Żeliński 11 grudnia 2012

      W sumie to mnie pocie­szy­łeś, bo BCE jest w moich oczach wła­śnie takim ​„odda­le­niem” od DDD dają­cym pole do popi­su deve­lo­pe­ro­wi, któ­ry.… wie­my. Często spo­ty­kam deve­lo­pe­rów uzur­pu­ją­cych sobie wyłącz­ne pra­wo do pro­jek­to­wa­nia mode­lu dzie­dzi­ny uzna­jąc, że wkra­czam w ich kom­pe­ten­cje, jed­nak czę­sto mam wra­że­nie, że te nie tyle ich kom­pe­ten­cje (bo tych czę­sto im wła­śnie brak) co chęć obro­ny tezy, że ​„kla­sy i cała ta obiek­tów­ka to ich zada­nie a nie ana­li­ty­ka” a prak­ty­ka moja jest taka, że po pro­tu uprasz­cza­ją sobie robo­tę… nie­ste­ty – jak słusz­nie zauwa­ży­łeś – zamy­ka­jąc sobie dro­gę do przy­szłej ​„gład­kiej” roz­bu­do­wy apli­ka­cji. Niestety to ostat­nie to raczej dro­ga w ​„gwa­ran­to­wa­nie” sobie dodat­ko­wych przy­cho­dów w przy­szło­ści, ale nie­ste­ty ma to krót­kie nogi…

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.