Analiza biznesowa i projektowanie
Wstęp
W artykule o aplikacjach webowych, ponad rok temu, pisałem:
Generalnie kluczową cechą micro-serwisów, czyniącą z nich tak zwaną zwinną architekturę, jest całkowita wzajemna niezależność implementacji poszczególnych usług aplikacyjnych. (źr.: Aplikacje webowe i mikroserwisy czyli architektura systemów webowych).
Przy innej okazji pisałem o wzorcach:
Wzorce projektowe to bardzo ważna część ??zawodu? analityka i architekta oprogramowania. […] Generalnie wzorce są to skatalogowane standardy i dobre praktyki . (Obiektowe wzorce projektowe )
Szkolenia dla analityków poprzedzam ankietami przed szkoleniowymi, jak do tej pory żadna nie zawierała pytań o wzorce projektowe: ani tego że są używane ani tego, że są celem szkolenia, niemalże każdy deklaruje albo, że używa UML lub, że chce zacząć używać UML, nawet gdy są to programiści. Zauważyłem, że wzorce projektowe w świadomości analizy biznesowej i projektowania (OOAD) „nie istnieją”. Wśród programistów, jeżeli jest spotykana, to wiedza o wzorcach przydatnych w tworzeniu bibliotek i narzędzi, często też powielane są wyuczone stare i złe praktyki programistyczne rodem z lat 60-tych (np. praktyki SmallTalk, patrz dalej).
Z drugiej strony od wielu lat znane są techniki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), które w różnych formach, ale jednak wskazują, że najskuteczniejsza forma wyrażania wymagań wobec rozwiązania to projekt architektury i logiki dziedzinowej (model) działania aplikacji . O projektowaniu poprzedzającym implementację pisze sie od dość dawna, metody obiektowe i dobre praktyki znane są od lat .
Autorzy BABoK praktycznie od początku istnienia tego wydawnictwa, zwracają uwagę na tak zwaną „białą skrzynkę”, czyli wymagania wyrażone w postaci wewnętrznej struktury produktu, wskazując, że to znacznie skuteczniejsza metoda definiowania wymagań wobec rozwiązania, niż tak zwana „czarna skrzynka”, czyli tradycyjne, i jednak mniej skuteczne, wymagania wyrażone tylko jako cechy funkcjonalne i poza-funkcjonalne. Pamiętajmy, że adresatem wymagań jest zawsze dostawca produktu!
Kluczowe definicje
Generalnie wzorzec projektowy (ang. design pattern) w inżynierii jest powszechnie definiowany jako: uniwersalne, sprawdzone w praktyce rozwiązanie. Kolejnym ważnym pojęciem jest polityka. Z perspektywy sposobu postępowania, słownik języka polskiego definiuje politykę jako: „zręczne i układne działanie w celu osiągnięcia określonych zamierzeń”.
Polityka (polityki) to pojęcie ogólniejsze niż wzorzec. Wyraża ona generalne zasady, te zaś dopiero implikują stosowanie określonych wzorców. Pozostaje ostatnie już ważne pojęcie: paradygmat: jest to przyjęty sposób widzenia rzeczywistości w danej dziedzinie, doktrynie itp. Np. polityką jest umowa (wymaganie), że stosujemy wzorce a paradygmatem to, że dowolną architekturę budujemy z niezależnych i samodzielnych mniejszych, współpracujących elementów.
Paradygmat obiektowy projektowania oprogramowania to przyjęcie założenia, że oprogramowanie to współpracujące obiekty (komponenty). Kluczową cechą obiektu jest to, że nie ujawnia on swojej wewnętrznej budowy (hermetyzacja) a jedyną formą współpracy obiektów jest ich reagowanie na wzajemnie przekazywane bodźce (wywołania, obiekt ma określone zachowania, więcej w artykule: paradygmat obiektowy). Reakcja na bodziec i wynik tej reakcji zależy od obiektu a nie od bodźca (polimorfizm: np. szyba i dzwon inaczej reagują na identyczne uderzenie młotkiem).
Definicja paradygmatu obiektowego jest praktycznie tożsama z ogólniejszą definicją, jaką jest definicja pojęcia «system»: zespół logicznie powiązanych, współpracujących elementów . Wielu autorów dodaje do tej definicji „w określonym celu”, co uważam za nadużycie, gdyż pojęcie cel oznacza czyjeś świadome działanie, zaś to, że otaczający nas świat można opisać (model) jako system, nie wynika z tego, że ktoś go celowo tak stworzył.
Na koniec definicja pojęcia pryncypium: najważniejsza dla kogoś lub dla czegoś zasada albo wartość.
Wzorce projektowe czy polityki tworzenia architektury?
Podstawową, moim zdaniem, zasadą świadomego zachowania jest jego celowość. Jeżeli więc stosujemy (jakieś) wzorce projektowe to należy określić cel ich stosowania.
Nie ma sensu stosowanie jakichkolwiek wzorców dla samego faktu ich stosowania, ale ich świadome stosowanie obniża ryzyko projektu i poprawia jego jakość.
Podstawowym celem inżynierii jest projektowanie rozwiązań, a ich kluczową, poza-funcjonalną, cechą są koszty utrzymania i rozwoju.
Wzorce projektowe to przede wszystkim dobre praktyki obniżające koszty utrzymania i rozwoju.
Postaram się pokazać (postawić tezę), że generalnie chodzi o pewne określone polityki projektowania architektury oprogramowania, a skupię się na specyfice modeli PIM .
Wzorce w literaturze
Literatura na temat wzorców projektowych jest bardzo bogata, myślę że czytelnik łatwo do niej dotrze (patrz mój artykuł cytowany na początku). W tym tekście skupię się na bardzo ważnym aspekcie tych wzorców, jakim jest model dziedziny systemu jako obszar ich stosowania.
Znakomita większość wzorców projektowych opisywanych w literaturze, dotyczy obszaru Control i View architektury MVC. Stosowanie ich w obszarze Model jest bardzo częstym zjawiskiem wśród programistów. Powielanie praktyk znanych z zaleceń C++ czy SmallTalk jest wręcz złym pomysłem (patrz podsumowanie). Czego więc powinni nauczyć się analitycy-projektanci? Tylko tego co wpływa na koszty utrzymania i rozwoju funkcjonalności systemu.
Środowiska wykonawcze (biblioteki, frameworki) zmieniają się dość wolno. Upgrade środowiska ma miejsce co kilka lat. Zmiany w funkcjonalności oprogramowania wspierającego zarzadzanie zachodzą w takt zmian prawa i rynku: nawet kilka razy w ciągu roku. Dlatego właśnie decyzje o zastosowaniu technik i wzorców projektowych należy podejmować w kontekście tego czy projektujemy: implementację logiki biznesowej czy środowisko aplikacji. To drugie stawia wyłącznie wymagania takie jak wydajność i niezawodność oraz kompatybilność.
Oprogramowanie biznesowe (mechanizm realizacji logiki biznesowej) ma nie tylko długi cykl życia ale i bardzo burzliwy.
Dlatego do realizacji Modelu Dziedziny (komponent realizujący logikę biznesową) wymagane jest inne podejście niż do realizacji wymagań poza-funkcjonalnych.
OCP jako miernik jakości architektury
Jedną z kluczowych cech architektury spełniającej powyższe, ekonomiczne, wymagania jest zasada OCP (Open-Closed Principle): oprogramowanie jest otwarte na rozszerzenia, ale zamknięte na zmiany. Oznacza to, że projektant będzie mógł (powinien móc) dodawać kolejne funkcjonalności do klasy (komponentu, systemu), ale nie będzie edytował obecnych już funkcji w sposób, który wpływa na istniejący pozostały kod, który z niego korzysta. Zasada ta jest częścią zestawu zasad zwanych SOLID, są wśród nich także: zasada pojedynczej odpowiedzialności klas (oznacza jeden kontekst a nie jedną operację), zasada segregacji interfejsów (to konsekwencja poprzedniej zasady) . Autor tej publikacji, na podstawie swoich badań, pisze:
Zgodnie z moimi badaniami i punktami, które omówiliśmy powyżej, wniosek jest taki, że nie ma [nie są stosowane] żadne konkretne zasady i regulacje w projektowaniu oprogramowania. Warto zauważyć, że projektowanie jest stylem, jednak nie wszystkie style przebadałem. Zaobserwowałem, że projektanci stosują różne podejścia, np. ta sama agencja Narodów Zjednoczonych raz stosuje opisane zasady a raz nie. Nadal nie ma żadnych zasad ani wskazówek, które stosowane były by we wszystkich przypadkach, chociaż, są próby sformalizowania „dążenia doskonałości”.
Moje wieloletnie obserwacje potwierdzają powyższe spostrzeżenia: wzorce i metody są od lat znane, jednak rzadko są stosowane. Warto tu zwrócić uwagę na fakt, że mamy rok 2021 a o wzorcach mówimy od początków metod obiektowych. Pozostaje pytanie: nie są powszechnie stosowane bo nie są dobre, czy nie są stosowane bo wiedza o nich jest nadal mało rozpowszechniona. A może są inne powody? Moim zdaniem wiedza ta jest powszechnie dostępna, ale nie jest popularna. Po drugie promowanie zwinności (czyli droga na skróty) skutkuje także ograniczaniem prac analitycznych i projektowych w początkowym etapie procesu tworzenia oprogramowania, i tu upatruję głównego powodu małej popularności wzorców: wymagają etapu analizy i projektowania. Analiza i projektowanie podnosi planowane koszty wytworzenia, ale praktyka okazuje nie jest prawdą, że wydłuża czas do pierwszego uruchomienia. Nie jest tajemnicą, że pierwszy etap (jego koszt) często decyduje o wyborze dostawcy, jednak mści się to wielokrotnie na etapie utrzymania i rozwoju.
Jaką wartość wnosi stosowanie wzorców? Pojawia się następujący tok uzasadnienia ich użycia:
- wyznacznikiem jakości oprogramowania są koszty w całym jego cyklu życia, a nie tylko na etapie wytwarzania i wdrażania,
- kluczem staje więc zasada OCP: oprogramowanie jest otwarte dla rozszerzenia, ale zamknięte na zmiany, co w konsekwencji pozwala na uzyskanie liniowego (zamiast wykładniczego) wzrostu łącznego kosztu rozwoju aplikacji: ponosimy koszt realizacji nowej potrzeby, bez dodatkowego kosztu aktualizacji (refaktoryzacja) już używanego,
- w konsekwencji zamiast monolitu, stosujemy architekturę komponentową (np. mikro serwisy, micro aplikacje),
- podstawową jednostką projektowania i rozwoju staje się Usługa Aplikacji modelowana w UML jako Przypadek Użycia (np. patrz Use Case 2.0),
- z uwagi więc na to, że każdy przypadek użycia to odrębny, separowany komponent, mający swój własny cykl życia, wymagający także utrzymania i rozwoju, wymienione zasady (wzorce projektowe) stosujemy także do projektowania jego wewnętrznej architektury.
System to jego architektura oraz zachowanie (struktura i reakcja całości na bodźce). Dlatego mówiąc o wzorcach projektowych, mówimy o wzorcach architektonicznych i o wzorcach zachowania. W tym opracowaniu skupię się głównie na wzorcach architektonicznych, o wzorcach (zasadach) zachowania wspomnę.
Architektura oparta na wzorcach – po kolei
Umowa na zakres czyli jakie usługi
Na tym etapie podejmujemy decyzję «Co i dla kogo aplikacja ma robić» (a nie JAK).

Diagram Przypadków Użycia to diagram pomocniczy w UML . Celem jego tworzenia jest zawarcie umowy na to co ma powstać (usługi) i dla kogo (aktor), czyli sprecyzowanie wymagań wobec systemu. Bardzo ważne: tu wymaganiem biznesowym (usługa aplikacyjna) jest to CO chce uzyskać Aktor Systemu a nie to JAK to będzie realizowane. Decyzja JAK jest decyzją projektanta rozwiązania, decyzja CO jest ustaleniem celu tworzenia oprogramowania. Usługa z perspektywy Aktora, to opis reakcji Systemu. Zachowanie bardzo często dokumentujemy, początkowo nieformalnie, w postaci procedury tekstowej (np. wypunktowana lista kolejnych kroków). Kolejny etap to iteracyjno-przyrostowa formalizacja opisu zachowania z pomocą diagramu aktywności lub sekwencji . Diagram aktywności to początkowo idea wzajemnej komunikacji komponentów, potem algorytmy i mechanizmy. Diagram sekwencji pokazuje już wzajemną komunikację komponentów w postaci wywoływanych operacji interfejsów (na diagramach aktywności także można to pokazać, jednak diagram sekwencji jest tu znacznie łatwiejszy do percepcji).
Architektura aplikacji
Tak zwaną architekturę wysokiego poziomu (ang. HLD, High Level Design) budujemy już na bazie wzorca mówiącego, że usługi aplikacji implementujemy jako odrębne komponenty, separujemy je także od reszty otoczenia. Idea takich mikroserwisów jest znana od dawna, jeden z najpopularniejszych chyba, znanych mi, schematów blokowych pokazuje to tak:
Więc nasza Aplikacja powinna mieć np. taką wewnętrzną architekturę:
Komponenty realizujące Usługi Aplikacji są integrowane w Portalu, zewnętrzne usługi są izolowane Adapterem. Zaleca to wielu producentów frameworków, np.:
Integracja wewnętrzna
W kolejnych krokach zajmiemy się logiką realizowaną przez komponenty odpowiedzialne za dostarczanie usług. Z uwagi na to, że zawsze należy się spodziewać wewnętrznej integracji (np. jeden komponent udostępnia Słownik dla drugiego) uzupełniamy nasz model o interfejsy:

Powyższy model to statyczny opis architektury. Opis zachowania, bazujący na wzorcu „Łańcuch odpowiedzialności” może wyglądać jak poniżej:

Architektura usługi aplikacji
W latach 90-tych powstał wzorzec BCE (ang. Boundary, Control, Entity) w ramach dość ciężkiej metodyki RUP (Rational Unified Process) i ICONIX . To były początki orientacji na komponenty i przypadki użycia. Inżynieria oprogramowania i wzorce ewoluują, postrzeganie tego wzorca także. Poniżej prosta architektura na bazie tego wzorca:
Wzorzec bazuje na zasadzie pojedynczej odpowiedzialności oraz na wzorcu zachowania: Kaskada (łańcuch) odpowiedzialności. Komponent Boundary odpowiada wyłącznie za dialog z Aktorem (interfejs). Komponent Control odpowiada wyłącznie za realizację logiki biznesowej (sterowanie), komponent Entity odpowiada wyłącznie za utrwalanie danych (pierwotnie były to obiekty DAO: ang. Data Access Object, stanowiące sobą zapytania SQL do relacyjnych baz danych).
Z perspektywy czasu zmieniło sie wiele ale nie paradygmaty. Obiektów Entity są setki, tysiące, a obecnie miliony (BigData) co może powodować problem z perspektywy logiki (Control), która z tej kolekcji danych korzysta. Do tego prostego wzorca dodajemy więc interfejs separujący logikę (Control) od ogromnej nie raz kolekcji obiektów, których jedyną rolą jest przechowywanie danych. Z uwagi na to, że kontrolowany dostęp do kolekcji obiektów to także logika, ikona klasy Entity Access (graficzne oznaczenie stereotypu) jest taka jak ikona komponentu Control:

Modyfikacja polega tu na tym, że kolekcję obiektów reprezentujących dane (obiekty klasy Entity) oddzielamy od reszty aplikacji (hermetyzujemy) za pomocą logiki realizującej interfejs do tej kolekcji. Ten komponent realizuje dostęp do danych, wyszukiwanie i zasady dostępu.
Obiekty Entity z zasady nie realizują żadnej logiki biznesowej, zachowują jedynie dane, mają wyłącznie operacje zapisz/przywołaj, tworzone i usuwane są przez logikę usługi lub przez dodatkową usługę, gdy zajdzie taka potrzeba. Atrybuty służą tu wyłącznie do indeksowania właściwa treść (JSON, XML) to zawartość jednego z atrybutów (patrz wzorzec Envelope ). Wzorzec ten (kolekcja obiektów i interfejs do niej) nazywa się Repozytorium (Repository). Komunikacja między logiką Entiry Access a Entity odbywa się na bazie wzorca publish/subscribe .
Jak wygląda tu rozwój i rozbudowa? Jeżeli modyfikacja nie wprowadza nowych wewnętrznych usług, a jedynie ulepsza (np. nowy lepszy algorytm) już istniejące, wystarczy zmiana, która „nie wyjdzie” poza modyfikowany komponent (hermetyzacja). Jeżeli dojdzie do rozbudowy funkcjonalności, należy zaprojektować nowy komponent i włączyć go do architektury:

Nowy komponent Control3 został dodany w sposób minimalizujący zmiany. Komponent Control2 praktycznie pełni role interfejsu do niego. Jest to bardzo wygodne, bo mógł to być np. komponent kupiony na rynku, z interfejsem (operacje) wymagającym dopasowania, wtedy Control2 pełni rolę interfejsu i adaptera (nie ma innego dojścia do Control3, jest on hermetyzowany w tej architekturze za komponentem Control2). Tak właśnie wygląda realizacja zasady OCP w toku rozwoju aplikacji.
Model danych
Naturalną formą zarządzania informacją są dokumenty a nie „relacyjne bazy danych”.
Relacyjny model danych opracował Edgar Codd w 1970 roku, jego celem i kluczową zaletą jest mechanizm spójności i transakcyjności zbioru danych (ACID). Model ten niestety jest bardzo nienaturalny z perspektywy dokumentów: w modelu relacyjnym ich po prostu nie ma. Warto pamiętać, że:
„Information Science includes two fundamentally different traditions: a „document” tradition concerned with signifying objects and their use; and a „computational” tradition of applying algorithmic, logical, mathematical, and mechanical techniques to information management. Both traditions have been deeply influenced by technological modernism: Technology, standards, systems and efficiency enable progress. Both traditions are needed. Information Science is rooted in part in humanities and qualitative social sciences. The landscape of Information science is complex. An ecumenical view is needed.” [Nauka o informacji obejmuje dwie zasadniczo różne tradycje: tradycję „dokumentową”, zajmującą się opisywaniem obiektów i ich wykorzystaniem, oraz tradycję „obliczeniową”, polegającą na zastosowaniu technik algorytmicznych, logicznych, matematycznych i mechanicznych do zarządzania informacją. Obie tradycje znalazły się pod głębokim wpływem modernizmu technologicznego: Technologia, standardy, systemy i wydajność umożliwiają postęp. Obie tradycje są potrzebne. Nauka o informacji jest częściowo zakorzeniona w naukach humanistycznych i jakościowych naukach społecznych. Krajobraz nauki o informacji jest złożony. Potrzebne jest spojrzenie ekumeniczne.]
Dlatego są obszary, w których model relacyjny sprawdza sie doskonale (obliczenia) i obszary, w których nie sprawdza się wcale (dokumenty).
NoSQL i dokumenty
Pojawiły się (prawie 20 lat temu) bazy NoSQL (Not only SQL). Porównania pokazują też, że bazy NoSQL (np. dokumentowe) oferują znacznie szybszy dostęp do danych . Porównania pokazują, że czas zapisu i dostępu do złożonych dokumentów w bazach NoSQL jest nawet o trzy rzędy (tysiąckrotnie!) krótszy niż w bazach SQL . Model relacyjny to sztywna struktura i po utworzeniu jest praktycznie niezmienny. Niestety w obecnych czasach stabilna na wiele lat struktura danych to praktycznie fikcja. Po drugie udział danych strukturalnych w ogólnej ilości zbieranych danych stale spada, ocenia się, że obecnie dane strukturalne to <10% ogółu zebranych danych (wiedzy). Dokumenty biznesowe, ich struktura, zmieniają sie wraz ze zmianami prawa i modeli biznesowych, czyli nie raz nawet częściej niż raz w roku. Dlatego oparcie się na dokumentowych wzorcach jest obecnie znacznie skuteczniejsze, mikroserwisy zresztą z zasady wykluczają monolityczne relacyjne bazy danych.
Rezygnacja z modeli relacyjnych znakomicie upraszcza etap analizy i projektowania, notacja UML od lat doskonale wspiera „nieesqelowe” metody projektowania oprogramowania, w tym dokumentowe (w szczególności XML) struktury danych . Warto zaznaczyć, że UML nie służy do modelowania danych w modelu relacyjnym!
Dane, biznesowe w szczególności, są organizowane w struktury dokumentowe, jest to ich naturalna postać (więcej na ten temat w artykule Struktury formularzy jako forma wyrażania wymagań).

W efekcie ostateczna postać modelu realizacji usługi ma postać:

Jak widać dane i ich struktury (dokumenty) są całkowicie oddzielone od metod ich tworzenia, korzyści z takiego podejścia opisuje Evans w DDD, rekomendacje takie można znaleźć u wielu innych autorów . Ten projekt nie wymaga żadnego SQL i relacyjnego modelu. Na etapie projektowania na pewno, a na etapie implementacji obecnie raczej też nie.
Architektura usługi to dość prosta struktura. Każdy konkretny przypadek użycia (usługa aplikacji) może być nieco inny, ale ogólna idea zastosowania zasad: łańcuch odpowiedzialności (nie pomijamy żadnego komponentu w drodze od aktora do dokumentu), repozytorium (interfejs do kolekcji obiektów biznesowych), i nowe zachowania, to nowe a nie zmienione, komponenty zorientowane na role. Całość daje bardzo przydatny zestaw tylko kilku wzorców na etapie analizy i projektowania modelu dziedziny systemu (komponent realizujący logikę biznesową, czyli wymagania funkcjonalne, to Model Dziedziny Systemu) . Model opisujący interakcje tych komponentów byłby zbudowany analogicznie jak wcześniej pokazany dla architektury HLD.
W realnym projekcie każda klasa miałaby oczywiście operacje. Tu tego nie pokazywałem by nie komplikować diagramów. Przykład realnego projektu wykonanego wg. powyższych reguł opisałem w artykule Inżynieria oprogramowania z użyciem narzędzia CASE ? przykładowy projekt. Szczegóły omawiam na szkoleniach: Analiza obiektowa i projektowanie logiki oprogramowania z użyciem notacji UML.
Podsumowanie
To co opisano to architektura komponentowa znana od ponad 20 lat . Orientacja na odpowiedzialność klas znana od 2003 roku, książka Rebeki Wirfs-Brock jest cyklicznie wznawiana . Także w 2003 roku, w duchu powyższych zasad, Eric Evans opisał wzorzec Domain Driven Design . Jest on nadal podstawą wielu frameworków.
Problemem jaki dostrzegam, jest uproszczona edukacja na studiach, zrównująca projektowanie obiektowe z programowaniem obiektowym. To co nazywamy programowaniem obiektowym jest często definiowane na bazie cech języka Smalltalk (Smalltalk ? najczystszy z obiektowych języków programowania) lub C++:
- Wszystko jest obiektem
- Każdy obiekt jest instancją klasy
- Każda klasa ma klasę nadrzędną
- Wszystko dzieje się przez wysyłanie wiadomości
- Wyszukiwanie metod używa łańcucha dziedziczenia
I to niestety jest kluczowe źródło wielu problemów. Punkt 3. jest jedną z najgorszych i najkosztowniejszych praktyk w obszarze modelu dziedziny, uzależniających definicje klas od siebie (łamanie kluczowej zasady jaką jest hermetyzacja). Punkt 5 jest w zasadzie martwy, bo metody albo są znane bo wymagane interfejsem, albo nie wiemy, że są (kosztowne, osierocone elementy kodu w wielu systemach). Dziedziczenie z zasady łamie hermetyzację (współdzielenie elementów kodu, przypominam, że dziedziczenie usunięto z UML w 2015 roku). Tak więc paradygmat obiektowy to po prostu komunikujące się obiekty i tak projektujemy. Klasy to wyłącznie definicje obiektów w kodzie źródłowym, i tak kodujemy (UWAGA! Kod programu wyrażony w języku obiektowym to metamodel działającego programu!). Typowymi popularnymi i złymi praktykami są umieszczanie metod kreacyjnych w ich klasach bazowych czy pobieranie i zapisywanie wartości atrybutów poleceniami get/set-atrybut. Szkodliwość tej drugiej praktyki opisał Fowler w DTO . Fowler jest autorem jednej z najpopularniejszych na świecie pozycji o wzorcach projektowych, mającej już kilka wznowień i aktualizacji .
Jak pokazano, analiza i projektowanie DOSKONALE obywa się bez SQL i relacyjnych modeli danych (nie używam ich na etapie analizy i projektowania od ponad 15 lat i nie jestem w tym osamotniony na świecie). Problem jaki stwarzają usilnie projektowane i realizowane „systemowe relacyjne modele danych” jest znany od dekad:

Odejście od tej praktyki (modele danych i SQL od samego początku analizy i projektowania) pozwala projektować aplikacje niezależnie od metod implementacji, zrozumiałe dla interesariuszy. Projekt rozwiązania na tym etapie (przed wyborem dostawcy) z zasady powinien abstrahować od implementacji (jest to model PIM, niezależny od platformy implementacji). Dzięki czemu cała dokumentacja, jeżeli zostanie napisana językiem i słownictwem interesariusza (patrz DDD), może być zrozumiała dla niego.
No i na koniec: chmurowe systemy utrwalania danych nie operują językiem SQL i relacyjnym modelem danych, więc pora w końcu zapomnieć o SQL i relacyjnie zorganizowanych danych na etapie analizy i projektowania. Zresztą dużych transakcyjnych systemów, niekorzystających z SQL i relacyjnego systemu organizacji danych, jest bardzo dużo, nie tylko sklep Amazon.
Lista wzorców wykorzystana w artykule
- BCE (Boundary, Control, Entity) – projektowanie zorientowane na odpowiedzialność klas: B – pośredniczenie pomiędzy aplikacją a jej otoczeniem, C – realizacja logiki dziedzinowej, E – utrwalanie,
- agregat – przechowywanie danych w zwartej, hermetycznej, hierarchicznej struktury (np. jako dokument, np. JSON, XML),
- saga – zarządzanie scenariuszami (sekwencje, procedury) z jednego miejsca,
- łańcuch odpowiedzialności – kaskadowe przekazywanie wywołań od interfejsu komponentu do danych z użyciem polimorfizmu,
- repozytorium – separowanie (hermetyzacja) danych i dostępu do danych od reszty aplikacji,
- micro serwis (lub mikro-aplikacja) – implementacja każdej usługi systemu jako odrębnego komponentu,
- fasada – zasłonięcie złożoności architektury aplikacji/komponentu, elementem realizującym „portal dostępowy” (są to często publiczne operacje interfejsu),
- adapter – izolowanie wewnętrznych komponentów aplikacji o jej otoczenia,
- envelope – przechowywanie danych (agregat) w indeksowanych prostszych obiektach,
- publish/subscribe – komunikacja np. pomiędzy obiektem kontrolującym dostęp do danych a nośnikami tych danych (entity) metodą wywoływania ich po ID,
- wszystkie powyższe praktycznie dotyczą także integracji aplikacji.
Dostępny jest warsztat, na którym może w praktyce poznać te wzorce i przećwiczyć ich stosowanie w praktyce: ZAPRASZAM.