Przeczytaj wersję webową.

Zdarzenia wyższego rzędu

Cześć !

Niekiedy problemy biznesowe są naprawdę nietrywialne. Ale może urodzić się z tego ciekawy koncept - zdarzenia wyższego rzędu.

Miałem niedawno warsztat z jedną firmą, z obszaru budowlanego. Planują stworzyć system do zarządzania od A do Z obszarem budowy - rozpoczynanie inwestycji / przetarg / przygotowanie do budowy / budowę / odbiory. Można by założyć, że analogicznie będą wyglądały moduły

Co tam jest ciekawe biznesowo:

• W ramach danego modułu każda firma ma inny zestaw dokumentów, o różnym procesie zatwierdzania ich.
  • To powoduje, że musimy napierw stworzyć „fabrykę dokumentów", gdzie definiujemy proces i rodzaj dokumentu.
  • Następnie na tej podstawie ludzie uruchamiają fabrykę tworząc konkretne dokumenty. Np. jedna firma dla obszaru przetargu będzie miała 2 rodzaje dokumentów, a druga 5 rodzajów.
• Ale, ale. W ramach danego modułu tylko jeden rodzaj dokumentu jest dokumentem kończącym pracę w module.
  • W zależności od firmy ten rodzaj dokumentu będzie różny, ale każda musi taki mieć. W “fabryce dokumentów” musimy wybrać które zdarzenie kończy proces.
  • Wtedy taki rodzaj dokumentów ma wpływ na pracę kolejnych modułów – np. zamyka przetarg i otwiera przygotowanie do budowy.

Z perspektywy zdarzeniowej widzę tutaj ciekawy przypadek:

• Niskopoziomowo musimy mieć dość ogólne zdarzenia w stylu StworzonoDokument / ZmienionoStatusDokumentu / ZakończonoDokument.
• Następnie w warstwie wyższej polityka będzie obsługiwała niskopoziomowe zdarzenia i je transformowała na bardziej biznesowe:
  • Na podstawie ustawień fabryki mapowałaby zdarzenie ZakończonoDokument z rodzaju ProtokółFinalnyPrzetargu na zdarzenie wysokopoziomowe ZakończonoPrzetarg.
  • Wtedy takie zdarzenie kończy pracę w jednym module i rozpoczyna proces w kolejnym.

Widzę tutaj nawiązanie do 16 rozdziału Domain-Driven Design Erica Evansa i modeli wielkiej skali. W nieco bardziej przystępny sposób opowiedział to Mariusz Gil na prezentacji N-warstwowe modele domenowe.

Daj znać co myślisz o tym pomyśle - sam się zastanawiam jak ten koncept traktować 🤔

PS. Kierowany problemami  z rozumieniem gdzie i kiedy stosować podejścia zwinne(bo nie ma słowa Agile w polskim słowniku) napisałem kolejny artykuł na bloga: Pracuj zwinnie lub nie

Zachęcam do przeczytania i hejtowania (jeśli kochasz pracę zwinną), bądź podziękowań (jeśli jednak lubisz bardziej pracować waterfallowo) 😀

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

P.S. Co myślisz o tym newsletterze? Odpisz :)