ICONIX czyli komponentowo zorientowany zwinny standard analizy i projektowania

Wprowadzenie O podobnej porze roku, w 2015 roku pisałem: W ICONIX moż­na z powo­dze­niem sto­so­wać ​„czy­sty” UML źr.: : ICONIX and Use Case Driven Object Modeling with UML - Jarosław Żeliński IT-Consulting ICONIX to w zasadzie fundament obiektowego, zorientowanego na przypadki użycia, projektowanie oprogramowania . Jest to od samego początku swojego istnienia, metoda klasyfikowana jako zwinna . Orientacja na Przypadki Użycia (use case driven) to obecnie kanon projektowania . Coraz popularniejszy wzorzec jakim są mikroserwisy staje się "normą" w projektowaniu architektury . Od samego początku ICONIX jest promowany jako "Zwinność bez…

Czytaj dalejICONIX czyli komponentowo zorientowany zwinny standard analizy i projektowania

Jak wyjść z długu technologicznego jakim jest centralny monolityczny system

Na temat tego jakim uciążliwym długiem technologicznym jest monolityczny system napisano wiele, dzisiaj kolejne dwie ciekawe pozycje literatury: CMMI Compliant Modernization Framework to Transform Legacy Systems oraz Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices . Pierwsza publikacja opisuje metodę zaplanowania wyjścia z długu technologicznego z perspektywy analizy biznesowej, druga opisuje możliwą realizację techniczną z perspektywy architektury aplikacji i ewolucyjnej migracji z architektury monolitycznej do komponentowej (mikro-serwisy). Czym jest monolit? Jest to system, którego architektura stanowi jeden niepodzielny blok realizujący funkcje biznesowe. Kluczową cechą i zarazem wadą,…

Czytaj dalejJak wyjść z długu technologicznego jakim jest centralny monolityczny system

Diagram Przypadków Użycia UML

Wstęp Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji – podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…

Czytaj dalejDiagram Przypadków Użycia UML

Practical Event-Driven Microservices Architecture

Practical Event-Driven Microservices Architecture Building Sustainable and Highly Scalable Event-Driven MicroservicesHugo Rocha ma prawie dziesięcioletnie doświadczenie w pracy z wysoce rozproszonymi, sterowanymi zdarzeniami architekturami mikroserwisów. Obecnie jest szefem inżynierii w wiodącej globalnej platformie ecommerce dla produktów luksusowych (Farfetch), świadczącej usługi dla milionów aktywnych użytkowników, wspieranej przez architekturę sterowaną zdarzeniami z setkami mikroserwisów przetwarzających setki zmian na sekundę. Wcześniej pracował dla kilku referencyjnych firm telekomunikacyjnych, które przechodziły od aplikacji monolitycznych do architektur zorientowanych na mikroserwisy. Hugo kierował kilkoma zespołami, które każdego dnia bezpośrednio stykają się z ograniczeniami architektur sterowanych zdarzeniami. Zaprojektował…

Czytaj dalejPractical Event-Driven Microservices Architecture
(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

Wprowadzenie W 2019 opisałem swoistą próbę rewitalizacji wzorca BCE (Boundary, Control, Entity). Po wielu latach używania tego wzorca i dwóch latach prób jego rewitalizacji uznałem jednak, że Zarzucam pra­ce nad wzor­cem BCE. Podstawowy powód to boga­ta lite­ra­tu­ra i utrwa­lo­ne zna­cze­nia pojęć opi­su­ją­cych ten wzo­rzec. Co do zasa­dy rede­fi­nio­wa­nie utrwa­lo­nych pojęć nie wno­si nicze­go do nauki. Moja publi­ka­cja zawie­ra­ją­ca tak­że opis tego wzor­ca bazo­wa­ła na pier­wot­nych zna­cze­niach pojęć Boundary, Control, Entity. Sprawiły one jed­nak nie­co pro­ble­mu w kolej­nej publi­ka­cji na temat dokumentów . Dlatego w mode­lu poję­cio­wym opi­su­ją­cym role kom­po­nen­tów przy­ją­łem nastę­pu­ją­ce bazo­we stwierdzenie:…

Czytaj dalejKoncepcja wzorca projektowego dla systemów w chmurze

Mikroserwisy c.d.?

Dwa lata temu pisałem o mikroserwisach: Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal jest problem ze zrozumieniem  ?kiedy i jak?. Ładnie to opisał swego czasu E.Evans przy okazji wzorca DDD, Tu poprzestanę jedynie na pojęciu bounded context czyli ?granica kontekstu?. Granica ta ma podwójne znaczenie: kontekst nadaje (zmienia) znaczenia w modelu pojęciowym (bałwan w kontekście zimy to co innego niż bałwan w kontekście członków zespołu projektowego) oraz kontekst  (bardzo często) wyznacza zakres projektu (inne aspekty wzorca DDD tu pominę). Pierwsza uwaga: kontekst dziedzinowy (pojęciowy) jest ważniejszy (powinien…

Czytaj dalejMikroserwisy c.d.?

Wzorzec CRUD dla przypadków użycia i mikroserwisy

Analizy biznesowe wymagają oderwania się od technokracji, nie ma czegoś takiego jak dziesiątki przypadków użycia dla jednej faktury, nie ma systemowych przypadków użycia (nawet w specyfikacji UML ich nie znajdziecie), są kompletne (dające jako efekt przydatne produkty) usługi aplikacyjne i korzystający z tych usług aktorzy, w tym inne aplikacje lub komponenty. Dokumentacje zawierające setki przypadków użycia to nieporozumienie, technokratyczni zabójcy projektów. Warto się zastanowić zanim powierzycie analizę i projekt logiki systemu technokratycznemu developerowi...

Czytaj dalejWzorzec CRUD dla przypadków użycia i mikroserwisy

Koniec treści

Nie ma więcej stron do załadowania