Een introductie in CQRS

2,772 views

Published on

Een introductie in CQRS, gepresenteerd tijdens

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,772
On SlideShare
0
From Embeds
0
Number of Embeds
41
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Layering: Opdeling naar verschillende verantwoordelijkheden. Dit is een goede ontwikkeling.Layers versus Tiers.Waar laten we (business) logica?
  • Jaren ‘90 -> nu: VB 1.0 (1991), Delphi, C++ windows development‘Click – and it works’ omgevingen
  • Centraliseren van business logic: Stored procedures.T-SQL, wie kent het?Wat is het meest krachtige paradigma voor beschijven van (business) logic?  OO !
  • Dus breng het onder in een apart onderdeel binnen je architectuur!Kort ingaan op de pijlen.
  • En waarlaten we andereonderdelen?
  • Nog een laag!
  • Nog een laag!
  • Nog een laag!
  • Op het eerste gezicht kan dit mooi met dezelfde representatieBij nader inzien zijn de karakteristieken vaak anders:Niet alles in 1 keer laden voor het webEvents over de lijn op het web? Comet? Fancy..Andere stijl van interactie mogelijk, andere representatie.. Gewenst
  • Meerdere views op dezelfde data.. En alles moet die lagen door..
  • Weer een representatie erbij in de applicatie:-Met een leuke extra verrassing erbijAns van gang drie trekt met haar net in elkaar gezette rapportje je peperdure net een paar maanden vlekkeloos draaiende applicatie zo in 1 keer onderuit! Knap!
  • Koppelingen:Weer een representatie dimensie erbijVaak ook veel custom werk per koppeling, parallel en in de tijd
  • - De datalaag is in dit model het integratiepunt waar alles bij elkaar komt- De RDBMS is vaak nog wel geclusterd, geshard en gefailovered te krijgen- Maar hoe schaal je de rest van je applicatie? Niet out-of the-box
  • Leuk maarKoppelingen tussen lagen blijftVerschillende representaties blijven lastigExterne koppelingen niet opgelost Only gets you so far
  • Zet de lagen op verschillende tiersGooi er heel veel hardware onderIn eerste instantie goedkoopLoopt tegen een grens aan – en hardEnKoppelingen tussen lagen blijftVerschillende representaties blijven lastigExterne koppelingen niet opgelost
  • Veel grote websites doen zoietsDe AppEngine doet zoietsLastig is dat wijzigingen elkaar in de datalaag pas tegenkomenJe kunt daar gaan voor volledige constistentie tussen clustered servers – maar dat kent zijn grenzen-En Session state? Distributed state server / of naar de datalaag of clients
  • Leuk: een parallel model Wat toon je in je rapporten, wat toon je in de normale presentatie laag. Dubbelop.. Waar zit de logica om je datamodel te interpreteren? In de business logic. Maar als je dbreplication gebruikt.. Nou ja, doe maar gewoon half weer hetzelfde in ETL / Rapporten
  • Sogydoetveel met Domain Driven Design. Volledigeloskoppeling van de business logica en dezecentraalstellen.Let op de pijlen!Schalenhiervankanwel, maar is direct niettriviaalVoorkomtwel (teveel) koppelingen: allesgaat via het domeinmodel, geenlagenbovenelkaar
  • Leuk: een parallel model Wat toon je in je rapporten, wat toon je in de normale presentatie laag. Dubbelop.. Waar zit de logica om je datamodel te interpreteren? In de business logic. Maar als je dbreplication gebruikt.. Nou ja, doe maar gewoon half weer hetzelfde in ETL / Rapporten
  • Leuk: een parallel model Wat toon je in je rapporten, wat toon je in de normale presentatie laag. Dubbelop.. Waar zit de logica om je datamodel te interpreteren? In de business logic. Maar als je dbreplication gebruikt.. Nou ja, doe maar gewoon half weer hetzelfde in ETL / Rapporten
  • Nog een laag!
  • Denk ook aan de Law of Demeter!
  • Bliki – Martin Fowler – Geniaal met namen!
  • Dit log is de state van je domeinAlleen inserts / toevoegingen!Write-once medium! -> hoe safe wil je het hebben?Snapshots voor performance behoud
  • Bliki – Martin Fowler – Geniaal met namen!
  • Gebruik hier voorbeeld van klas & kind: state van een kind is niet direct die van de klas. Messaging (events) noodzakelijk.
  • Gebruik hier voorbeeld van klas & kind: state van een kind is niet direct die van de klas. Messaging (events) noodzakelijk.
  • Bliki – Martin Fowler – Geniaal met namen!
  • Deze queries en results kunnen helemaal toegespitst worden op de gui waar ze in gebruikt worden
  • Write & Read model zijn verschillende bounded contexten.. -Relaxed consistency tussen verschillende bounded contexts is eigenlijk normaal-Voordeel: normaal gesproken is tussen bounded contexts een leidend-volgend relatie
  • Write & Read model zijn verschillende bounded contexten.. -Relaxed consistency tussen verschillende bounded contexts is eigenlijk normaal-Voordeel: normaal gesproken is tussen bounded contexts een leidend-volgend relatie
  • Dit is op acceptance testing niveau. Sluit niet uit dat je nog lager niveau test
  • Probleem van wat er nou precies gebeurt: geldt voor OO als geheelIs een gevolg van de stijl om complexiteit (precieze handelingen) achter een interface weg te stoppenCommands: t.t. – Events v.v.t.
  • Een introductie in CQRS

    1. 1. Sogyo Café Schaalbaarheid CQRS Rick van der Arend – rvdarend@sogyo.nl
    2. 2. Agenda  Voorstellen  State of the Art  Problemen  Oplossingen  CQRS  Nadelen  Afronding SOFTWARE INNOVATORS 2
    3. 3. Voorstellen SOFTWARE INNOVATORS 3
    4. 4. Wie ben ik?  Rick van der Arend  Sogyo Consultancy ▫ Architect/Developer ▫ Consultant ▫ Coach SOFTWARE INNOVATORS 4
    5. 5. Wat we doen  Detachering  Opleiding  Development  Software innovatie SOFTWARE INNOVATORS 5
    6. 6. State of the Art SOFTWARE INNOVATORS 6
    7. 7. State of the Art  Op het gebied van applicatie architecturen  Van een monoliet...  ... naar layering SOFTWARE INNOVATORS 7
    8. 8. De monoliet User Interface ‘Monoliet’ Database SOFTWARE INNOVATORS 8
    9. 9. Layering Presentation Layer Data Layer 9
    10. 10. Layering Presentation Layer Business logic Data Layer 10
    11. 11. Layering Presentation Layer Business logic Data Layer 11
    12. 12. Layering: de drie lagen Presentation Layer Business logic Data Layer 12
    13. 13. Layering Where? Presentation Layer Printing Business logic Logging Email SMS Data Layer 13
    14. 14. Layering: laag #4 Presentation Layer Service Layer Business logic Data Layer SOFTWARE INNOVATORS 14
    15. 15. Problemen SOFTWARE INNOVATORS 15
    16. 16. Problemen  Koppelingen tussen de lagen  Meerdere representaties  Externe koppelingen  Lage schaalbaarheid SOFTWARE INNOVATORS 16
    17. 17. State of the Art Presentation Layer Service Layer Business logic Data Layer SOFTWARE INNOVATORS 17
    18. 18. Ontkoppelde lagen? Form Row Presentation Layer DTO DTO Service Layer OBJ Business logic OBJ Row Data Layer Row SOFTWARE INNOVATORS 18
    19. 19. Representaties: clients Fat client Web client Service Layer Business logic Data Layer SOFTWARE INNOVATORS 19
    20. 20. Representaties: user roles Publiek Intranet Team Service Layer Business logic Data Layer SOFTWARE INNOVATORS 20
    21. 21. Representaties: reports Presentation Layer Reports Service Layer Business logic Data Layer SOFTWARE INNOVATORS 21
    22. 22. Externe koppelingen UI WS #1 WS #2 .. Service Layer Business logic Data Layer SOFTWARE INNOVATORS 22
    23. 23. Schaalbaarheid 1 2 3 .. N Service Layer Business logic Data Layer -1 Data Layer - 2 Data Layer - 3 SOFTWARE INNOVATORS 23
    24. 24. Oplossingen SOFTWARE INNOVATORS 24
    25. 25. Oplossingen  Multi-Tier  Verticaal schalen  Horizontaal schalen  Rapportages apart  Satellietmodel SOFTWARE INNOVATORS 25
    26. 26. Multi-Tier Presentation Layer Service Layer Business logic Data Layer SOFTWARE INNOVATORS 26
    27. 27. Verticaal schalen Presentation Layer Service Layer Business logic Data Layer SOFTWARE INNOVATORS 27
    28. 28. Horizontaal schalen 1 2 3 .. N Load balancer Service Layer Service Layer Service Layer Business logic Business logic Business logic Data Layer -1 Data Layer - 2 Data Layer - 3 SOFTWARE INNOVATORS 28
    29. 29. Rapportages apart (BI/DWH) Presentation Layer Presentation Layer Service Layer Rapportage server Business logic Rapportages Data Layer Rapportage DB SOFTWARE INNOVATORS 29
    30. 30. Beyond layering…  Een onafhankelijk domeinmodel 30
    31. 31. CQRS SOFTWARE INNOVATORS 31
    32. 32. Terug naar af Wat zijn de problemen in een notedop? Presentation Layer • Wijzigingen en queries gaan helemaal naar beneden • Results komen helemaal terug Service Layer • M.a.w. de lagen zijn gekoppeld • Er is niet één representatie • N representaties in 1 model Business logic • Externe koppelingen = werk • Opschalen is moeilijk Data Layer SOFTWARE INNOVATORS 32
    33. 33. Rapportages apart (BI/DWH) Presentation Layer Presentation Layer Service Layer Rapportage server Business logic Rapportages Data Layer Rapportage DB SOFTWARE INNOVATORS 33
    34. 34. Dat smaakt naar meer... Kan dat niet strikter? SOFTWARE INNOVATORS 34
    35. 35. CQRS! Commands Queries Presentation Layer Presentation Layer Service Layer Rapportage server Business logic Rapportages Data Layer Rapportage DB SOFTWARE INNOVATORS 35
    36. 36. CQRS Command-Query Responsibility Segregation SOFTWARE INNOVATORS 36
    37. 37. Waarom geen ‘separation’? Command-Query Responsibility SeGREGation SOFTWARE INNOVATORS 37
    38. 38. Dat ging even te snel.. Waarom wil je dit? SOFTWARE INNOVATORS 38
    39. 39. Getters en Setters Presentation Layer Service Layer Als dit een OO- domeinmodel is, dan heb je hierin veel Business logic getters en setters Data Layer SOFTWARE INNOVATORS 39
    40. 40. Whatever happened to... Tell, don’t ask. SOFTWARE INNOVATORS 40
    41. 41. Tell, don’t Ask Is een principe dat je helpt om:  Koppelingen minimaal te houden  State+methodes van een verantwoordelijkheid te concentreren bij 1 object (..achter 1 interface) SOFTWARE INNOVATORS 41
    42. 42. Van setters naar commands  Setters zetten properties  Wie valideert de state?  Validatie over verschillende properties? Ewww  Domein veranderingen zijn belangrijke elementen om te modelleren > onderdeel UL  Zorg dat veranderingen mappen op methodes  Een methode aanroep + params = command SOFTWARE INNOVATORS 42
    43. 43. CqRs Kortom: alleen commands op het domein uitvoeren SOFTWARE INNOVATORS 43
    44. 44. Dat klinkt heel leuk, maar.. Waar query je dan op? SOFTWARE INNOVATORS 44
    45. 45. Niet op je domein... ..maar state veranderingen moeten wel naar buiten Events! SOFTWARE INNOVATORS 45
    46. 46. Met een mooi woord.. Event Sourcing SOFTWARE INNOVATORS 46
    47. 47. Events: nu ook voor persistentie ... beter dan logging! SOFTWARE INNOVATORS 47
    48. 48. Alles in één groot domein dus... Schaalt dát dan wel? SOFTWARE INNOVATORS 48
    49. 49. Aggregates SOFTWARE INNOVATORS 49
    50. 50. ... voor ontkoppeling in het domein  1 command mapt op 1 methode  Die ene methode hoort bij 1 Aggregate  En zit op de Aggregate Root  Een Aggragate is een consistentie grens  Elke Aggregate is consistent (invariants gelden)  1 command > 1 Transactie > 1 AR > 1+ Events  Met zijn events kan een Aggregate weer opgebouwd worden. SOFTWARE INNOVATORS 50
    51. 51. Ok, de write side is gedekt Maar stel dat de gebruiker eerst iets wil zien? Enter ? Command: >_ SOFTWARE INNOVATORS 51
    52. 52. Queries  Uit het domein komen events na state changes  Vang deze events op en update een read model  Relational database?  Platte html?  Voer queries uit op dit read model  En voedt de GUI met de results  Gebruik bijvoorbeeld.. databinding? SOFTWARE INNOVATORS 52
    53. 53. Het plaatje compleet... SOFTWARE INNOVATORS 53
    54. 54. Extra’s met event sourcing Met elk event kunnen:  Verschillende read models tegelijkertijd aangepast worden  Meerdere, dezelfde read models tegelijkertijd aangepast worden, voor eenvoudig opschalen Nodig:  Een eventbus waar deze models aan hangen  Bij intensief gebruik: relaxed consistency SOFTWARE INNOVATORS 54
    55. 55. Meer extra’s: externe koppeling 1. Een andere applicatie wil onze gegevens? 2. Publiceer de events op een externe eventbus 3. Klaar SOFTWARE INNOVATORS 55
    56. 56. Meer extra’s: user intent  In plaats van de laatste state  + wat (onvolledige?) logs  Hebben we nu een volledig & consistent log van alle state wijzigingen  En slaan we de commands óók op, dan kunnen zien wat er gebeurd is, niet alleen het resultaat SOFTWARE INNOVATORS 56
    57. 57. Zou deze gebruiker boek 1 interessant vinden? Koop Pak boek Verwijder Pak boek alles in 1 boek 1 2 mandje SOFTWARE INNOVATORS 57
    58. 58. Meer extra’s: testen  Given: <List of Events>  When: <Command> is fired  Then: <List of Events> is expected SOFTWARE INNOVATORS 58
    59. 59. Meer extra’s: rollout & debugging Moet een nieuwe versie live?  Laat hem schaduw draaien  Bekijk de commands en events  Schakel over wanneer vertrouwd Toch een fout?  Complete log van commands & events  Debugging geen probleem  Compensating action mogelijk SOFTWARE INNOVATORS 59
    60. 60. CQRS? SOFTWARE INNOVATORS 60
    61. 61. CQRS & Circular Architecture SOFTWARE INNOVATORS 61
    62. 62. Nadelen SOFTWARE INNOVATORS 62
    63. 63. Nadelen Als gevolg van:  Nieuwigheid  Ontkoppeling  Relaxed consistency SOFTWARE INNOVATORS 63
    64. 64. Als gevolg van Nieuwigheid  Ontwikkelaars nog niet bekend hiermee  Nog weinig ondersteuning van frameworks ▫ Wel al enkele: Axon, Ncqrs, voorbeeld apps  Database admin moet wennen aan andere rol ▫ Maar misschien is ‘God’ zijn ook wel wat te zwaar SOFTWARE INNOVATORS 64
    65. 65. Als gevolg van Ontkoppeling Task based UI, Domeinmodel, Readmodel, Events  Veel werk ten opzichte van two-way databinding ▫ Maar wie heeft dát echt zien werken? ▫ In een serieuze applicatie?  Minder inzichtelijk ‘wat er nou precies gebeurt’ ▫ Alternatief is: meer koppeling ▫ Op te lossen door goede naamgeving ▫ Naamgeving is sowieso zeer belangrijk SOFTWARE INNOVATORS 65
    66. 66. Als gevolg van Relaxed consistency  Relaxed consistency moet uitgelegd worden ▫ Klinkt eng ▫ Beter is om het te hebben over stale data ▫ En data die je bekijkt is altijd stale!  Maar in sommige gevallen is uitvoering van een command afhankelijk van de volledig state ▫ Bekend voorbeeld: de unieke username ▫ Best op te lossen door niet alles synchroon te doen SOFTWARE INNOVATORS 66
    67. 67. Samenvatting SOFTWARE INNOVATORS 67
    68. 68. Samenvatting Het vertrouwde lagenmodel kent problemen  Veel koppeling tussen lagen  Meerdere representaties (modellen) door elkaar  Externe koppeling veel maatwerk  Slechte inherente schaalbaarheid
    69. 69. Samenvatting Command-Query Responsibility Segregation levert, in combinatie met Event Sourcing ▫ Sterkere ontkoppeling, meerdere read modellen, ‘gratis’ externe API en betere schaalbaarheid Plus extra’s zoals: ▫ Behoud van user intent ▫ Event log die als audit log kan dienen ▫ Een simpele interface om te testen ▫ Bedrijfszekere rollout en ingebouwde debugging  Maar zoals altijd geldt: niet geschikt voor alles…
    70. 70. Meer weten?  http://CodeBetter.com – Greg Young  http://UdiDahan.com – Udi Dahan  http://software-innovators.nl  De DDD discussion group domaindrivendesign@yahoogroups.com  Een groeiend aantal blogs, sites en presentaties SOFTWARE INNOVATORS 70
    71. 71. Vragen? SOFTWARE INNOVATORS 71 71
    72. 72. Contact Rick van der Arend rvdarend@sogyo.nl 030 - 220 22 16 Web: www.sogyo.nl Blog: www.software–innovators.nl SOFTWARE INNOVATORS 72

    ×