Diagram: Jeden model dwa konteksty Diagram przedstawia obiekty biznesowe - dokumenty () pochodzące z dwóch różnych kontaktów. Na schemacie mamy trzy klasyfikatory reprezentujące dokumenty i ich struktury. W celu usunięcia kolizji pojęć opisanej przez Fowlera (FOWLER 2014) obiekty funkcjonujące w dwóch różnych kontaktach zostały rozdzielone na dwie kontekstowe przestrzenie pojęciowe: Sprzedaż oraz Serwis. W kontekście Sprzedaż pojęcia Klient i Produkt zostały użyte do nazwania obiektów biznesowych będących przedmiotami mającymi tożsamość. W kontekście Serwis pojęcia te (klient i produkt) ca jedynie cechami (atrybutami) obiektu biznesowego Uszkodzenie, słowa te (pojęcia) stanowią jedynie nazwy atrybutów a konkretne nazwy klienta i produktu stanowią wartość tych atrybutów i jako obiekty nie mają tu tożsamości (value UML i value object w DDD). Tak więc problem kolizji nazewnictwa została rozwiązany, warto tu zwrócić, że zbudowanie jednej spójnej relacyjnej bazy danych dla wszystkich pojęć obu tych dziedzin jest niemożliwe bez dodatkowych zabiegów z nazewnictwem.

Modelowanie architektury HLD i LLD usług aplikacji – modelowanie podsystemów

Wstęp

Tym razem krót­ki arty­kuł na temat pew­nej cie­ka­wej kon­struk­cji. Została ona opi­sa­na przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdo­był sobie wte­dy raczej zbyt dużej popu­lar­no­ści, jed­nak obec­nie, w dobie wzor­ców opar­tych o mikro­ser­wi­sy i mikro apli­ka­cje, ma szan­sę wró­cić do łask. Ja sto­su­ję go już od pew­ne­go cza­su. Skróty HLD i LLD to odpo­wied­nio: High-Level Design (pro­jekt wyso­kie­go pozio­mu) i Low-Level Design (pro­jekt niskie­go pozio­mu). Są to pozio­my abs­trak­cji w mode­lu PIM

Pakiet w UML

W nota­cji UML pakie­ty są ele­men­tem gru­pu­ją­cym, zapew­nia­ją moż­li­wość struk­tu­ry­za­cji i orga­ni­za­cji ele­men­tów mode­li UML. Specjalnym typem pakie­tu jest wła­śnie model :

Diagram pro­fi­lu dla ele­men­tu Pakiet (Package) w nota­cji UML. Stereotyp «Model» to typ Pakietu (gene­ra­li­za­cja u dołu diagramu)

Pakiet, jako ele­ment gru­pu­ją­cy ele­men­ty, może więc nie tyl­ko repre­zen­to­wać (ozna­czać) abs­trak­cję kom­po­nen­tu, ale tak­że gru­po­wać jego ele­men­ty i opi­sy­wać ich struk­tu­rę: wraz zawar­to­ścią może sta­no­wić model. 

Pakiet jako podsystem

Skorzystała z tego Rebeka Wirfs-Brock, pro­po­nu­jąc bar­dzo uży­tecz­ną konstrukcję:

A UML package is an appropriate container for the objects, relationships and other model elements that are the parts of a subsystem. The package will also hold other
model elements that help specify the way these parts work together, for example, collaborations
and interactions.

Skoro więc pakiet może gru­po­wać cokol­wiek”, może więc w szcze­gól­no­ści gru­po­wać ele­men­ty mode­lu­ją­ce np. usłu­gę apli­ka­cji na pozio­mie spe­cy­fi­ka­cji i realizacji. 

Standardowo w UML moż­na, dla usys­te­ma­ty­zo­wa­nia mode­lu i struk­tu­ry repo­zy­to­rium, two­rzyć kon­struk­cje jak poniżej:

Przypadek uży­cia i jego realizacja. 

Wirfs-Brock pro­po­nu­je umiesz­cze­nie abs­trak­cji przy­pad­ku uży­cia wewnątrz pakie­tu, któ­ry gra­ficz­nie jest dedy­ko­wa­nym sym­bo­lem dla ste­reo­ty­pu «sub­sys­tem»:

Przypadek uży­cia oraz jego reali­za­cja wewnątrz pakie­tu ozna­cza­ją­ce­go Podsystem 

Standardowy kształt repre­zen­tu­ją­cy pakiet na dia­gra­mach, został podzie­lo­ny na obsza­ry: ope­ra­cje, spe­cy­fi­ka­cja, reali­za­cja. Główną zale­tą tej kon­struk­cji, w porów­na­niu z tra­dy­cyj­ną”, jest moż­li­wość upo­rząd­ko­wa­nia tre­ści dia­gra­mu i struk­tu­ry repo­zy­to­rium, poprzez umiesz­cze­nie abs­trak­cji spe­cy­fi­ka­cji usłu­gi wewnątrz pakie­tu, któ­ry repre­zen­tu­je tak­że jej reali­za­cję (archi­tek­tu­rę).

W przy­pad­ku gdy uży­je­my tej kon­struk­cji do orga­ni­zo­wa­nia mode­li usług apli­ka­cji (przy­pad­ków uży­cia), wyglą­da to jak na dia­gra­mie powy­żej. Konstrukcji tej moż­na użyć z powo­dze­niem do innych wewnętrz­nych kom­po­nen­tów, dla­te­go mamy do dys­po­zy­cji dodat­ko­wą prze­strzeń na poka­za­nie nazw ope­ra­cji kom­po­nen­tu (pakiet, zgod­nie z MOF, to tak­że klasyfikator). 

W pro­jek­tach reali­zo­wa­nych od ogó­łu do szcze­gó­łu, korzy­sta­nie z tej kon­struk­cji jest to bar­dzo przy­dat­ną meto­dą, bo pozwa­la zade­kla­ro­wać ele­ment mode­lu­ją­cy kom­po­nent, a póź­niej wypeł­nić go tre­ścią, zacho­wu­jąc od począt­ku spój­ną, hie­rar­chicz­ną struk­tu­rę pro­jek­tu i repozytorium

Przykład

Przykładowa struk­tu­ra dla dwóch przy­pad­ków uży­cia wyglą­da jak poniżej:

Struktura mode­li (dia­gra­mów) pro­jek­tu archi­tek­tu­ry sys­te­mu mają­ce­go dwa przy­pad­ki uży­cia: gór­na część to HLD, dol­na to LLD, czy­li wewnętrz­ne deta­le (archi­tek­tu­ra) kom­po­nen­tów archi­tek­tu­ry HLD.

Powyższy sche­mat obra­zu­je struk­tu­rę diagramów:

  • dia­gram przy­pad­ków uży­cia to naj­wyż­szy poziom abs­trak­cji: spe­cy­fi­ku­je umo­wą jako listę wyma­ga­nych usług systemu,
  • kolej­ny u góry po pra­wej jeden dia­gram, to model archi­tek­tu­ry wyso­kie­go pozio­mu (HLD) tego sys­te­mu, gdzie każ­dy przy­pa­dek uży­cia to osob­ny kom­po­nent (np. mikro­ser­wis) mają­cy swo­ją imple­men­ta­cję, taki model poka­zu­je tak­że wewnętrz­ną inte­gra­cję tych kom­po­nen­tów oraz ewen­tu­al­ną inte­gra­cję z oto­cze­niem (inne systemy),
  • każ­dy kom­po­nent, reali­zu­ją­cy okre­ślo­ny przy­pa­dek uży­cia, ma swo­ją odręb­ną wewnętrz­ną archi­tek­tu­rę (LLD).

Powyższe sta­no­wi pro­stą i sku­tecz­ną meto­dę porząd­ko­wa­nia ele­men­tów mode­li, zgod­ną z UML więc nie powin­no być pro­ble­mu z wyko­na­niem takie­go dia­gra­mu, a jak widać nie­któ­re narzę­dzia (tu Visual Paradigm) są do tego przygotowane. 

Podsumowanie

Czy ma sens takie mode­lo­wa­nie? Dlaczego nie zacząć od razu kodo­wać? W małym pro­jek­cie zapew­ne było­by to prze­ro­stem for­my nad tre­ścią (ale nie zawsze!). Jednak więk­sze pro­jek­ty reali­zo­wa­ne od razu w kodzie”, mają ogrom­ne pro­ble­my ze spój­no­ścią, sepa­ra­cją domen (dzie­dzi­na sys­te­mu i model poję­cio­wy ) oraz z podej­mo­wa­niem decy­zji w jakiej kolej­no­ści i co ma powsta­wać, bo z zasa­dy nie powsta­nie od razu cały sys­tem (patrz tak­że recen­zja książ­ki: Marsz ku klę­sce).

Do tego nale­ży dodać typo­we obec­nie wyma­ga­nie biz­ne­so­we: nie chce­my i nie może­my cze­kać na ukoń­cze­nie i odda­nie całe­go sys­te­mu, chce­my mieć moż­li­wość jak naj­szyb­sze­go uspraw­nie­nia pra­cy i roz­po­czę­cia korzy­sta­nia z wybra­nych usług sys­te­mu. Pozostałe mogą być wdra­ża­ne w umó­wio­nej kolej­no­ści, wraz z upły­wem cza­su. Więc na pew­no nie może to być monolit.

Jest to moż­li­we pod jed­nym warun­kiem: całość musi zostać podzie­lo­na na odręb­ne i samo­dziel­ne kom­po­nen­ty pierw­sze­go dnia pro­jek­tu”. Innymi sło­wy: pro­jekt zaczy­na­my zawsze od opra­co­wa­nia archi­tek­tu­ry cało­ści sys­te­mu (HLD), a potem kolej­no (ite­ra­cyj­nie) dopra­co­wu­je­my deta­le każ­de­go kom­po­nen­tu (LLD) i dostar­cza­my je klientowi.

Kolejny powód do mode­lo­wa­nia, szcze­gól­nie HLD, to inte­gra­cja. Otóż, jeże­li uznać, że żad­na apli­ka­cja biz­ne­so­wa nie dzia­ła samo­dziel­nie, a zawsze jako ele­ment więk­szej cało­ści, to zna­czy, że: żaden sys­tem nie jest mały”, że jest zawsze czę­ścią nad­rzęd­ne­go sys­te­mu, sys­te­mu wspie­ra­ją­ce­go całą orga­ni­za­cję, jej dostaw­ców i odbior­ców, to zna­czy, że

real­nie zawsze mode­lu­je­my duży sys­tem” lub jego inte­gral­ną część. 

To zaś ozna­cza, że zawsze nale­ży wyko­nać (mieć) model HLD sys­te­mu całej orga­ni­za­cji. Bez tego nie jest moż­li­wa ana­li­za wpły­wu: na co w fir­mie ma wpływ ten mały” sys­tem, któ­ry wła­śnie wdra­ża­my lub modyfikujemy.

Źródła

Wirfs-Brock, R., & McKean, A. (2006). Object Design: Roles, Responsibilities and Collaborations,. 88.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Martin Fowler. (2014). bli­ki: BoundedContext [Martinfowler​.com]. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml
Miller, J., & Wirfs-Brock, R. (1999). How Can a Subsystem Be Both a Package and a Classifier? https://​doi​.org/​1​0​.​1​0​0​7/3 – 540-46852 – 8_41

Inne artykuły na podobny temat

Dodaj komentarz

Twój adres email nie zostanie opublikowany

System komentarzy służy także do uzyskania konsultacji u autora tekstu, w przedmiocie treści artykułu.

Identyfikator *
E-mail *
Witryna internetowa

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