Szoftvertechnolgia s Grafikus Felhasznli Fellet Tervezse Flexible layering
Szoftvertechnológia és Grafikus Felhasználói Felület Tervezése Flexible layering (DDD, CQRS) Event-driven Architecture, Event Sourcing http: //users. nik. uni-obuda. hu/prog 4/ 1
Rétegek – Prog 3
Rétegek – Prog 4 3
Flexibilis rétegzés • Nem kell feltétlenül mindig ugyanazokat a rétegeket végigjárni – Nem feltétlenül a user használja a rendszert – Automata teszt – API végpontok – Parancssori scriptek – Saját és külső automatizmusok • Egyes funkciókra mindegyik rétegben szükség van, ezeket nem feltétlenül kötjük egy konkrét réteghez Naplózás, Messenger, Security … Cross cutting concerns / Aspect-oriented programming • Nem kell az összes BL feletti réteg, az azonos műveletekre másmás felsőbb rétegek szükségesek a különböző elérési módokhoz Onion/Hexagon architecture 4
Cross cutting concerns (Aspects) 5
Onion architecture 6
Hexagon architecture (adapters, ports…) 7
Teljesen új megközelítés: DDD • A Hexagon esetén a rétegek változtatása port/adaptertől függ, és lehetővé tesszük bizonyos modulok rétegtől független elérését • A klasszikus rétegzés ennél többet nem tud nyújtani • Martin Fowler, Vaughn Vernon , Eric Evans, Udi Dahan Domain Driven Design a rétegzés ne attól függjön, hogy Web vagy UI vagy API, hanem attól, hogy mit akarok csinálni az adattal! 8
Martin Fowler Patterns • Patterns of Enterprise Application Architecture (2003/2004) • Refactoring (Improving the Design of Existing Code, 2018 2 nd ed) • https: //martinfowler. com/books/eaa. html 9
EAA - Contents 1. 1. Domain Logic Patterns ○ Transaction Script ○ Domain Model Ma ○ Table Module ○ Service Layer Ma 2. Data Source Architectural Patterns ORM ○ Table Data Gateway ○ Row Data Gateway ○ Active Record ○ Data Mapper ORM/Ma 3. Object-Relational Behavioral Patterns ORM ○ Unit of Work Lehetséges Prog 3 bővítés ○ Identity Map ORM ○ Lazy Load ORM/Prog 4 10
EAA - Contents 2. 4. Object-Relational Structural Patterns ORM ○ Identity Field ○ Foreign Key Mapping ○ Association Table Mapping ○ Dependent Mapping ○ Embedded Value ○ Serialized LOB ○ Single Table Inheritance ○ Class Table Inheritance ○ Concrete Table Inheritance ○ Inheritance Mappers 5. Object-Relational Metadata Mapping Patterns ○ Metadata Mapping Az összes ORM ○ Query Object Doctrine ORM (Query builder) ○ Repository Prog 3 / Anti-Pattern? 11
EAA - Contents 3. 6. Web Presentation Patterns ○ Model View Controller Prog 4 ○ Page Controller ○ Front Controller ○ Template View Prog 4 ○ Transform View ○ Two Step View ○ Application Controller 7. Distribution Patterns ○ Remote Facade ○ Data Transfer Object Prog 4 8. Offline Concurrency Patterns ○ Optimistic Offline Lock Entity Framework ○ Pessimistic Offline Lock ○ Coarse-Grained Lock ○ Implicit Lock 12
EAA - Contents 4. 9. Session State patterns ASP. NET ○ Client Session State ○ Server Session State ○ Database Session State 10. Base Patterns ○ Gateway ○ Mapper ○ Layer Supertype ○ Separated Interface Prog 3 ○ Registry ○ Value Object ○ Money ○ Special Case ○ Plugin Prog 3 Chaser ○ Service Stub Ma ○ Record Set 13
Domain Driven Design – Components 14
Domain Models • A DDD menedzsment & szervezési tényezőket is figyelembe vesz • Alapvető különbség, hogy NEM az adatbázissal kezdjük a modellezést, hanem az üzleti oldalról – Ehhez szükség van egy közös nyelvre („Ubiquitous Language”, „a model-based language to connect domain experts, developers, and the code itself”), ezzel most nem foglalkozunk • Mi a rétegzésre összpontosítunk, ehhez Bounded Context -eket kell megtalálni, amikhez domain modelt kell létrehozni – Simple Domain Model (Active Record), nem a legjobb – Inkább: Rich Domain Model, nem kell a domain modelnek adatbázishoz közelítenie (ezért jó az előző félévben bemutatott Data Mapper / ORM) – Vigyázat: Bloated domain objects (túl sok felelősség) / Anemic domain objects (túl kevés felelősség), nehéz megtalálni a középutat 15
DDD Rich Domain Model forget DRY 16
A Domain Model után • A Domain Model egységbe zárja a domain entity-ket és azok üzleti műveleteit – a UI nem használja ezeket közvetlenül! • A DDD jól illik a SOA filozófiához (Service-Oriented Architecture), és manapság a „Microservices”ként ismert (jövő hét) • Modulok = service kapcsolatok, itt (is) Martin Fowler a nagy név • Tényleg platform- és nyelvfüggetlen felbontás • A Service Layer fontos, hogy Facade-ként működjön: „It encapsulates the business logic, it DOES NOT define the business logic!” 17
Service Layer • Feladata a hívások fogadása, továbbítása a Domain Logic és az Application Logic felé – Domain Logic: üzleti logikai műveletek – Application Logic (Workflow Logic): adminisztratív felelősségek (üzenetküldés, ütemezett feladatok, frissítések, stb…) • A Service Layer feladata lehet a tranzakciókezelés/lock is – Az alsóbb rétegekben ugyanúgy létezik adatbázis-szintű tranzakciókezelés, és szál-ütemezés is – Service Layerben ez sokszor a „Unit of Work” tervezési minta egyik változatát követi: „A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work. ” – Azonos stratégia, csak a Microservice szintjén 18
Saga • Microservice szintjén egy másik pattern is előjön kicsit más megvalósításban: Memento • Előző állapot visszaálítása subsystem/tranzakció szinten („Longrunning transaction state tracker”) 19
Saga • Tipikusan akkor használt, ha a szolgáltatások nem egyből kapnak választ (ami elég gyakori lehet, lásd később: Event Sourcing) • Hosszan futó szolgáltatásoknál megvalósuló tranzakció-kezelés • Minden folyamat (Activity) képes kell hogy legyen végrehajtásra, és visszavonásra. A több Activity-t kezelő State. Tracker kezeli az egyes sikeres/sikertelen folyamatokat, illetve kezeli a folyamatokból összerakott Queue-t 20
Service Stub • Microservice környezetben teljesen mindegy, hogy egy alrendszer helyi, vagy távoli • Tesztelés közben ugyanúgy mockolni kell a szolgáltatásokat (interfésszel) 21
Monolithic vs Microservice
Service Layer the real DDD way! • A UI csak egy service a sokból, a többi szolgáltatást felhasználva működnek az OLVASÓ műveletek – „Dashboard” és „Reports” funkcionalitás nagyon gyakran használt – Sokszor több Bounded Context-ből kell összelapátolni az adatokat lassít (group by / join) – Olvasáskor nem kell egy csomó olyan művelet, ami miatt a szolgáltatásokat használjuk: validáció, naplózás, stb… • Adat ÍRÁSAKOR ugyanúgy szolgáltatás on keresztül dolgozunk – Viszont tipikusan egyetlen Bounded Context –be írunk adatokat (ritka az olyan mentés, ami több féle adatot ment) – Szükségünk van a teljes funkcionalitásra, mert hibás adat elmentése után nem tudunk vele dolgozni, és a kijavítása is nagyon nehéz – Általában sokkal KEVESEBB az író művelet, mint az olvasó 23
DDD írás / olvasás 24
CQRS (Martin Fowler, DB szétvágás nélkül) 25
Megoldás: CQRS+DDD • Command-Query Responsibility Segregation (Martin Fowler) • A Query (lekérdező/olvasó) oldal egyszerűsítése Nincs szükségünk az összes rétegre 26
CQRS+DDD • A több Bounded Contextből összelapátolt adat tovább gyorsítható – A user MINDIG régi adatot lát – számít, hogy fél másodperces, vagy 10 perces, vagy 2 napos az adat? – Nyugodtan használhatunk a Bounded Contextektől független, a felhasználói felületekre jellemző, időnként frissülő tárolót A felületekre jellemző táblák (trend: denormalizált/no. SQL rekordok) 27
CQRS+DDD (Egyszerűsítve) 28
CQRS • Ez nem egy univerzális megközelítés! Bizonyos Use Case-ek esetén nem használható • Query oldalon probléma: egyedi keresések – Optimalizálható fulltext search módszerekkel (ebben a relációs adatbázisok egyre jobbak, de nem véletlenül áll a db-engines. com/en/ranking-ben 8. helyen az Elastic. Search) – Van olyan, hogy egyedi keresés? (auto*. fr: nincs ) • Command oldalon fellépő problémák – A failure ritka, és akkor is elég emailben értesíteni – Szinkron hibajelzés feleslegesen lassít – Természeténél fogva aszinkron (ld. Event Sourcing ezután) – A View. Model storage azonnali frissítése lassú, de csak bizonyos esetben (pl. ár módosítása) nem megkerülhető 29
Event-driven Architecture • A CQRS aszinkron működéséhez jól illeszkedő megközelítés • Az utasításokat egyből fel kell dolgozni? Ritkán – Sok esetben fontos a sorrend: tárgyfelvétel … – Az azonnali válasz fontossága a usertől és a use case-től függ (nem lenne jó, ha 10 perc múlva jönne egy email, hogy sikerült – e felvenni a tárgyakat…) – Adatmódosító utasítások esetén is néha gond lehet, ha nem egyből történik a mentés, ezeket azonosítani kell – Ugyanakkor, sok esetben (megrendelés, jelentkezés, hozzászólás, üzenetküldés, értékelés) abszolút nem gond, ha a „sikeres vásárlás” válasz után 7 perccel történik a vásárlás feldolgozása… – Ez különösen akkor jó, ha nagyon sok ritkán elhasaló tranzakciónk van (Például: o*. uk) 30
Event-driven Architecture • Az erőforrások kezelésén túl másik előny: flexibilitás • Ehhez nézzünk egyszerű példát: Hány darab, megadott számsorozattal kezdődő telefonszám van? $ cat phone. Numbers. txt | grep ^079 | wc -l 3 • És mi van, ha ehhez hozzá akarjuk rakni, hogy ÖSSZESEN hány telefonszámból van ez a három? • Klasszikus programnál ez bonyolult, az összes réteget módosítani kell • Eseményvezérelt architektúra esetén kevesebbet kell módosítani 31
Event-driven Architecture 3 phone numbers matched 32
Event-driven Architecture 3 of 15 phone numbers matched 33
Event sourcing 34
Event sourcing • Az események az Event Store adatbázisba kerülnek • A események feldolgozását tipikusan egy No. SQL / Queue adatbázis (Redis, Rabbit. MQ, MQTT/Hive. MQ: jövő hét) végzi, a nagy Event Store lehet relációs és No. SQL adatbázis is • Az események feldolgozása nem feltétlenül azonnali 35
Event sourcing nélkül 36
Event sourcing 37
CQRS (+ Event sourcing, DB szétvágás nélkül) • Command Bus: Queue, Event Bus: Broker (jövő hét) • A „Database” itt is szétvágható: Business DB + Persistent VM DB 38
Event sourcing + CQRS + DDD • Előnyök – Teljesítmény – Teljes visszakövethetőség („Audit Trail”) – Egyszerűbb a rendszerek összeépítése – Az Event Store-ból extra üzleti adat is kinyerhető, több fajta jelentés lehetséges – Könnyebb hibakeresés, tesztelés • Hátrányok – Részletes aggregálás/report nehezebb – A jelentések elkészítése több szakértelmet igényel – Hibás request visszajelzése nem feltétlenül azonnali – Nagyobb tárigény – Ez NEM egy mindenhol használható megközelítés!!! 39
Köszönöm a figyelmet! Flexible layering (DDD, CQRS) Event-driven Architecture, Event Sourcing http: //users. nik. uni-obuda. hu/prog 4/ 40
- Slides: 40