ICONIX jako obiektowo zorientowany, zwinny proces projektowania oprogramowania z użyciem notacji UML

Wprowadzenie "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią". Głównym wyróżnikiem ICONIX jest wypełnienie luki pomiędzy analizą potrzeb a implementacją. Lukę tę wypełniamy od razu modelując mechanizm realizacji przypadków użycia. Proces ten sprawia,…

Czytaj dalejICONIX jako obiektowo zorientowany, zwinny proces projektowania oprogramowania z użyciem notacji 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

Koniec treści

Nie ma więcej stron do załadowania