CQRS recipes or how to cook your architecture

Download CQRS recipes or how to cook your architecture

Post on 12-Jul-2015

7.350 views

Category:

Technology

0 download

Embed Size (px)

TRANSCRIPT

<p>Slide 1</p> <p>CQRS recipes or how to cook your architecture@tjaskula</p> <p>But before we dive into CQRS recipeswe have to understand basic layered onesMaslow pyramid in meal recipesNot official, just my own tripHey! How this relates to architecture mate?</p> <p>Maslow architecture pyramid?This should somehow mapBut first lets tell a little storyof one e-commerce application that Ive learnt so hard</p> <p>Once upon a time a marketing team came into announce to developers what they have sold</p> <p>We need an e-commerce portal. Now!Do it fastWe need every feature Orders, Product catalog, Suppliers</p> <p>Development has startedIn progressThen the developer has came after a while</p> <p>E-Commerce portal architectureUIDomainDALDB12Another feature was asked by the business</p> <p>But developers just</p> <p>It will take another year. Because weve built a</p> <p>Explain what is monolith15We need to refactor. Business wants more featuresHow to refactor a monolith?</p> <p>To decouple every component, you have. </p> <p>Evolve domain independently, it should. </p> <p>Handle business needs easier, you will. </p> <p>Decouple componentsHandle business logic in isolated domainWe have to think it over, but for now lets wrap up what weve learntWrite unit test because every change is a breaking one</p> <p>Lesson learnt 1Recipe 1:Basic layered architecture</p> <p>Recipe 1Basic layered architectureIngredientsBasic coding skillsSome infrastructure pieces (DB, etc.)Client reviews Can be set up very quickly Easy to understand No need for experienced developers. Juniors can make it </p> <p> Leads quickly to unmaintainable monolith code blocks Not easily evolvable for quickly changing business requirements Not scalable Not performent if charge gets bigger Not testable. Youd better have end-to-end integration testsDifficulty:</p> <p>Time: from 25 min to infinityPreparation:Just throw basic code skills in. Mix it up with a database and UI and everything will be fineor notUIDomainDALDBWhere weve been?Ah yeahDECOUPLING stuffThen this came inLets decouple ourselves from DB</p> <p>And decouple us from everything elseIoC container FTW!</p> <p>AndAnd</p> <p>Business ask more futures for Orders, Suppliers, stuff</p> <p>UIOrderViewModelOrderOrderControllerOrderMapperIOrderMapperSqlOrderRepositoryIOrderRepositoryDBPresentationDomainInfrastructureArchitecture v2What's the problem with n-layered architectures?What's the problem with n-layered architectures ?</p> <p>Reused Abstraction Principle</p> <p>VIOLATED* RAP principle violated (Reused Abstraction Principle). Interface are not a guarantee of abstraction. We end up with one implementation per interface* Interfaces should be discovered and not invented.29Over time, more features, more pain* RAP principle violated (Reused Abstraction Principle). Interface are not a guarantee of abstraction. We end up with one implementation per interface* Interfaces should be discovered and not invented.30Because ofpublic class OrderController {public OrderController (IOrderValidator order validator,IOrderMapper orderMapper,IOrderRepository orderRepositoryISupplierRepository supplierRepositoryIAuthorizationFactory authorizationFactory,IUnitOfWork unitOfWork,IUserFactory userFactoryISession session,ILogger logger,IOrderCache orderCache) {}}* RAP principle violated (Reused Abstraction Principle). Interface are not a guarantee of abstraction. We end up with one implementation per interface* Interfaces should be discovered and not invented.31And because developers spent their time on</p> <p>32It seems that after a while we have still a monolith</p> <p>Explain what is monolith33But decoupled Explain what is monolith34We need more data on UI and different views per user</p> <p>But our model doesnt support it</p> <p>Every time we add a new view our model is brokenViews are slower. Users complainYour reads from writes separate. Herh herh herh.</p> <p>CQRS, you will do !</p> <p>We have to think about it</p> <p>Time to wrap upLesson learnt 2Recipe 1:Basic layered architectureRecipe 2:n-layered architecture with DI</p> <p>Recipe 2N-layered architecture with DIIngredientsOOP skillsWith SOLID principles would be event betterORMs and IOCsSome infrastructure pieces (DB, etc.)Client reviews Can be set up rather quickly Easy to understand Can be tested</p> <p> Can lead to unmaintainable monolith code blocks Not easily evolvable for quickly changing business requirements Not scalable Not performent if charge gets biggerDifficulty:</p> <p>Time: reasonablePreparation:One must know OOP concepts and the best would be also to be aware of SOLID principlesUIOrderViewModelOrderOrderControllerOrderMapperIOrderMapperSqlOrderRepositoryIOrderRepositoryDBWhere weve been?Ah yeahCQRS stuffWhat is CQRS?CQS applied to architecture = CQRSSplit Read from Writes</p> <p>42 UIDomainRepositoryDB Write DB ReadRead Model Application serviceCommandQueryArchitecture v3Command UIDomainRepositoryDB WriteRead Model Application serviceDB ReaddenormalizedQueryArchitecture v3 bisWow, the speed of views has increased</p> <p>We can scale up read and write side independentlyEasy to handle more business request about views and queries in denormalized DBEven of its better we still have problems</p> <p>Why we have impacts between different business lines?Why it takes so much time for a new feature? And we always dont get exactly what we want. There is always a confusion.Integration inside of the business</p> <p>CRUD events ?CQRS not a top level architectureWhere it should be used ? Where there is a valueConcurrent domain / Performances optimizations47 Composite UIUIData Access LayerWeb / Application TierBackground server TierStorage TierDDD layered applicationWrite modelReadmodelLegacy applicationDomain ADomain BDomain CDomain DCRUD architecture (simple non-core domain functionality)DDD (core domain functionality)CQRS (core domain functionality)Legacy subsystem48How to know where to put the effort?</p> <p>What is the strategic advantage of my company?</p> <p>50Order management system is our strategic goal</p> <p>Great then we know where to put our effort</p> <p>But how do we find the best model for a business</p> <p>To them about events talk. </p> <p>Find it meaningful, will they. Yeesssssss.</p> <p>The quest has startedEvent Storming = Domain Discovery Tool</p> <p>source : Brandolini http://bit.ly/1s1dwoBIt's about communication and not design55Events, thats the way we think about it!</p> <p>From events, to aggregatesIts DDD!</p> <p>Domain Driven DesignIts much more than just commands and events Ubiquitous Language Bounded Context Context Map Domain Event AggregatesLook no repositoriesAt a high level, a context map can help you understand the integration between the different bounded contexts and the events involved58We need a new feature concert ticket sell</p> <p>Done!</p> <p>System is unusable users are blocked!!!</p> <p>Ah no, what to do?</p> <p>Express business intent in commands and facts in events, you will.</p> <p>Make events asynchronous, you will. Herh herh herh.</p> <p>We have to think about it</p> <p>Time to wrap upLesson learnt 3Recipe 1:Basic layered architectureRecipe 2:n-layered architecture with DIRecipe 3:Hexagonal with basic CQRS</p> <p>Recipe 3Basic CQRSIngredientsOOP skillsSOLID principlesDomain Driven Design would be a big advantageClient reviews Scale out read from writes independently Can handle more business request about queries More maintainable code Even easier to test</p> <p>Users still can be blocked read and write are synchronous Not so performent for big chargesDifficulty:</p> <p>Time: mid-termPreparation:Establish a ubiquitous language with your domain experts and express it in the code UIDomainRepositoryDB WriteRead Model Application serviceDB ReaddenormalizedWhere weve been?Ah yeah commands and eventsasynchronousCommand, its business intent like Place Order</p> <p>Event, its business immutable fact like OrderPlacedArchitecture v4DomainRepositoryDB WriteRead Model Application serviceDB ReadUICommand HandlerCommand BusEvent BusRead model generatorAnother context applicationCommandEventDependency69DomainRepositoryDB WriteRead Model Application serviceDB ReadDB WriteRead Model Application serviceDB ReadCommand HandlerCommand BusEvent BusRead model generatorACLCommand HandlerDomainRepositoryRead model generatorUICommandEventDependencyArchitecture v470DomainRepositoryDB WriteRead Model Application serviceDB ReadDB WriteApplication serviceUICommand HandlerCommand BusEvent BusRead model generatorACLCommand HandlerDomainRepositoryCommandEventDependencyArchitecture v471But there is a trap. Views are not refreshed immediately</p> <p>CAP Theorem*CQRS IngredientsConsistency:A read sees all previously completed writesAvailability:Reads and writes always succeedPartition tolerance:Guaranteed properties are maintained even when network failures prevent some machines from communicating with others* Eric BrewerA system can be either CP, AP. CA is not coherent.73CAP TheoremCQRS IngredientsCPAPNode 1Node 2Node 1Node 2DataDataDataData74Eventual ConsistencyCQRS IngredientsA key benefit of embracing eventual consistency is to remove the requirement for using distributed transactionsUsers deal every day with Eventual Consistency75But there is still a trap with event synchronization</p> <p>Write sideRead sideUIWrite ModelDB WriteRead ModelDB ReadUpdate write side data storeUpdate read side data storeRead dataTransaction Scope77Write sideRead sideUIWrite ModelDB WriteRead ModelDB ReadUpdate write side data storeSend message to update read side data storeRead dataTransaction ScopeEvent BusReliable messaging78Write sideRead sideUIWrite ModelDB WriteRead ModelDB ReadUpdate write side data storeSend message to update read side data storeRead dataTransaction ScopeEvent BusReliable messaging79I would like to know if user before placing an Order removes Items if we propose them more useful articles with our recommendation system</p> <p>Thats a tricky question. We dont have a history.</p> <p>All you need, you have.Use your events, you will. Yeesssssss.</p> <p>We have to think about it</p> <p>Time to wrap upLesson learnt 4Recipe 1:Basic layered architectureRecipe 2:n-layered architecture with DIRecipe 3:Hexagonal with basic CQRSRecipe 4:Hexagonalish with CQRS + DDD</p> <p>Recipe 4Basic CQRS + DDD + AsyncIngredientsGood OOP skillsSOLID principlesDomain Driven Design modelingGood knowledge of messaging infrastructureClient reviews Handles concurrent domains Scale out read from writes independently Can handle more business request about queries Business process explicit Even easier to test</p> <p> Many moving parts Sometimes integration points between systems are harder to grasp Bad things can happen if no integration events command are storedDifficulty:</p> <p>Time: long termPreparation:Gather business intent in form of Commands, map it to business events and synchronize everything async.DomainRepositoryDB WriteRead Model Application serviceDB ReadDB WriteApplication serviceUICommand HandlerCommand BusEvent BusRead model generatorACLCommand HandlerDomainRepositoryWhere weve been?Ah yeah storing eventsFor legal thing, we would like an audit log</p> <p>If we got a time machine</p> <p>Yes you have it. Events = facts</p> <p>Event SourcingCQRS IngredientsEvent as a storage mechanismOrderOrder line ItemShipping informationOrder CreatedAdded 2 items 245Added 3 items 455Removed 2 items 245Added shipping infoOrder placedAppend only system</p> <p>90Event SourcingRolling snapshotOrder CreatedAdded 2 items 245Added 3 items 455Removed 2 items 245Added shipping infoOrder placedSnapshotPut on stackAdded 3 items 455Removed 2 items 245Added shipping infoOrder placedSnapshotAppend only system</p> <p>91DomainEvent StoreRead Model Application serviceDB ReadUICommand HandlerCommand BusEvent BusRead model generatorAnother context applicationCommandEventDependency92DomainEvent StoreRead Model Application serviceDB ReadDB WriteRead Model Application serviceDB ReadUICommand HandlerCommand BusEvent BusRead model generatorACLCommand HandlerDomainRepositoryRead model generatorCommandEventDependency93DomainEvent StoreRead Model Application serviceUICommand HandlerCommand BusEvent BusAnother context applicationCommandEventDependency94Our system seems to be on the right track now !</p> <p>Lesson learn 5Recipe 1:Basic layered architectureRecipe 2:n-layered architecture with DIRecipe 3:Hexagonal with basic CQRSRecipe 4:Hexagonalish with CQRS + DDDRecipe 5:Hexagonalish with CQRS + DDD + ES</p> <p>Recipe 5Basic CQRS + DDD + ESIngredientsGood OOP skillsSOLID principlesDomain Driven Design modelingGood knowledge of messaging infrastructureFunctional thinkingClient reviews Handles concurrent domains Scale out read from writes independently Can handle more business request about queries Business process explicit Audit log, testing and infinite business views on data</p> <p> Many moving parts Sometimes integration points between systems are harder to grasp Bad things can happen if no integration events command are storedDifficulty:</p> <p>Time: long termPreparation:Make your events talk.DomainEvent StoreRead Model Application serviceDB ReadDB WriteRead Model Application serviceDB ReadUICommand HandlerCommand BusEvent BusRead model generatorACLCommand HandlerDomainRepositoryRead model generatorMaslow architecture pyramidNot official, just my own tripWhat CQRS is not?CQRS Basics/From CQS to CQRS</p> <p>99Is CQRS for me?CQRS Basics/From CQS to CQRSWhat kind of problem do I try to solve ?Collaborative domainLocking the data without blocking the userRead data scalabilityPerformance optimizationComplex workflows / Temporal data / Stale data100There is moreAggregates Validation Uniqueness checking Existence checking Replaying of events (Event Sourced)Long running workflowsOptimizationLong running process: saga and process managerOptimization : command without messaging, commands in parallel</p> <p>101Long running workflowsCQRS Deep Dive CookingHow do I know if I need one?Difference between Saga and Process Manager?102ClientOrder Process ManagerOrder AggregateStock AggregatePayment Aggregate1. Place Order2. OrderPlaced3. Make reservation4. ItemsReserved5. Make payment6. PaymentAccepted7. OrderConfirmed7. OrderConfirmed7. OrderConfirmed103Questions ?104</p>