CQRS and Event Sourcing, An Alternative Architecture for DDD

73,403 views

Published on

Most of us will be familiar with the standard 3- or 4-layer architecture you often see in larger enterprise systems. Some are already practicing Domain Driven Design and work together with the business to clarify the domain concepts. Perhaps you’ve noticed that is difficult to get the intention of the 'verbs' from that domain into this standard architecture. If performance is an important requirement as well, then you might have discovered that an Object-Relational Mapper and a relational database are not always the best solution.

One of the main reasons for this is the fact that the interests of a consistent domain that takes into account the many business rules, and those of data reporting and presentation are conflicting. That’s why Betrand Meyer introduced the Command Query Separation principle.

An architecture based on this principle combined with the Event Sourcing concept provides the ideal architecture for building high-performance systems designed using DDD. Well-known bloggers like Udi Dahan and Greg Young have already spent quite a lot of of posts on this, and this year’s Developer Days had some coverage as well.

But how do you build such a system with the. NET framework? Is it really as complex as some claim, or is just different work?

Published in: Technology
2 Comments
87 Likes
Statistics
Notes
  • Good introduction on CQRS architecture, with practical suggestions.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • vffvfv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
73,403
On SlideShare
0
From Embeds
0
Number of Embeds
40,056
Actions
Shares
0
Downloads
0
Comments
2
Likes
87
Embeds 0
No embeds

No notes for slide
  • DisadvantagesNo concurrency; conflicting service requests are simply rejectedStaleness ignored;Scalability limited; No domain verbs; domain model does contain concepts from the domain model, just not the business actionsGranularity DTOs; What operations to expose in your WCF service? What relations to include and when? What domain entities to flatten.Unneccesary DTO conversions; Conversions from/to domain model entities, traversing of relations, eager fatchingConflicting demands; query demands denormalized schema, commands require normalized integer schema
  • DisadvantagesNo concurrency; conflicting service requests are simply rejectedStaleness ignored;Scalability limited; No domain verbs; domain model does contain concepts from the domain model, just not the business actionsGranularity DTOs; What operations to expose in your WCF service? What relations to include and when? What domain entities to flatten.Unneccesary DTO conversions; Conversions from/to domain model entities, traversing of relations, eager fatchingConflicting demands; query demands denormalized schema, commands require normalized integer schema
  • Commands validate itself without using any context, thus is valid or not instead of sometimes.Commands are named in the Ubiquitous LanguageCommands can be send asynchronously, and thus can be resistent to database unavailabilityMogelijk meerdere commands met dezeflde state change: CorrectCustomerAddress, MoveCustomerCommand interfaces: in-memory, WCF, WCF RIA Services, NServiceBus, etc
  • DisadvantagesNo concurrency; conflicting service requests are simply rejectedStaleness ignored;Scalability limited; No domain verbs; domain model does contain concepts from the domain model, just not the business actionsGranularity DTOs; What operations to expose in your WCF service? What relations to include and when? What domain entities to flatten.Unneccesary DTO conversions; Conversions from/to domain model entities, traversing of relations, eager fatchingConflicting demands; query demands denormalized schema, commands require normalized integer schema
  • DisadvantagesNo concurrency; conflicting service requests are simply rejectedStaleness ignored;Scalability limited; No domain verbs; domain model does contain concepts from the domain model, just not the business actionsGranularity DTOs; What operations to expose in your WCF service? What relations to include and when? What domain entities to flatten.Unneccesary DTO conversions; Conversions from/to domain model entities, traversing of relations, eager fatchingConflicting demands; query demands denormalized schema, commands require normalized integer schema
  • CQRS and Event Sourcing, An Alternative Architecture for DDD

    1. 1. CQRS & Event Sourcing<br />An alternative architecture for DDD<br />Dennis Doomen<br />
    2. 2. The default architecture<br />A better architecture<br />The alternative architecture<br />Advanced topics <br />Contents<br />
    3. 3. The Default Architecture<br />Easy to build<br />Accepted by management<br />Well known<br />Lots of resources<br />Lots of frameworks<br />Silverlight Application<br />No concurrency<br />Scalability limited<br />No domain verbs<br />Granularity DTOs<br />Unneccesary DTO conversions<br />Conflicting demands<br />Proxy<br />DTOs<br />Services<br />Domain Services<br />Domain Model<br />Repositories<br />Unit of Work<br />Service Agents<br />RelationalDatabase<br />Backoffice Systems<br />
    4. 4. CQRS<br />Silverlight Application<br />Commands are verbs<br />No DTO conversion<br />Easy to build disconnected clients<br />Query Store = No SQL<br />Very scalable<br />Service Agent<br />Queries<br />Business Actions<br />DTOs<br />Commands<br />Command Service<br />Query Service<br />Command Handlers<br />Domain Services<br />Domain Model<br />Data Access Layer<br />Repositories<br />UoW<br />Service Agents<br />Difficult to sync database<br />No concurrency<br />Requires a task-based UI<br />Complexity<br />RelationalDatabase<br />Query Store<br />Backoffice Systems<br />Changes<br />Query Store<br />
    5. 5. Task-based UIs a.k.a. Inductive UIs answer:<br />What am I supposed to do now?<br />Where do I go from here to accomplish my task?<br />Task-based UIs<br />
    6. 6. Focus screens on single task<br />Make the task’s intention clear<br />Offer links to secondary tasks<br />Provide screens for starting tasks<br />Make the next step obvious<br />From Microsoft Inductive User Interface Guidelines<br />Guidelines for Task-based UIs<br />
    7. 7. Are valid or not, regardless of context<br />Named in Ubiquitous Language<br />State intent<br />Can be asynchronous...<br />...but beware of eventual consistency<br />Rejection via exception or fault event<br />Commands<br />
    8. 8. One table per UI view<br />Exposed through <br />SOA-style web services<br />WCF data services<br />WCF RIA Services<br />Can be anything<br />Relational Database<br />No SQL database<br />XML files<br />Query Store<br />
    9. 9. CQRS & Event Sourcing<br />Silverlight Application<br />Great performance<br />Conflict Merging<br />Historical Tracking<br />Trival Synchronization<br />Easy Integration<br />Independent Query Store <br />Queries<br />Service Agent<br />Business Actions<br />Commands<br />DTOs<br />Command Service<br />Command Handlers<br />Domain Services<br />Domain Model<br />Events<br />Query Service<br />Denormalizer<br />Events<br />Event Handlers<br />Lots of new concepts<br />Not so acceptable<br />Few resources<br />No consensus yet<br />More complexity<br />Aggregate boundaries important<br />Data Access Layer<br />UoW<br />Event Bus<br />Domain Repository<br />Service Agents<br />Query Store<br />Event Store<br />Query Store<br />Backoffice Systems<br />Events<br />
    10. 10. Represent state changes in aggregate root<br />Named in passed tense<br />Using Ubiquitous Language<br />Entire aggregate is stored in serialized format<br />Events never change<br />Snapshots to improve performance<br />Events<br />
    11. 11. Have no relationships (!)<br />Communicate through events<br />Entities do not expose setters (!)<br />Apply events to themselves<br />State exposed as mementos<br />Aggregate Roots<br />
    12. 12. Conflict Merging<br />
    13. 13. Event Schema Versioning<br />- Adds missing properties<br />- Renames renamed properties<br />- Converts values<br />Post Converter<br />Property Bag Converter<br />Post Converter<br />Post Converter<br />id = 123<br />SQL Server<br />Domain Repository<br />Event Store<br />Property<br />Bag<br />Get(id = 123)<br />Event<br />id = 123<br />
    14. 14. Event Store != relational database...so no unique constraints<br />Workarounds<br />Check uniqueness through query side<br />Add generic unique column to event store<br />Introduce a parent that enforces uniqueness<br />Unique Constraints<br />
    15. 15. The CQRS Kitchen<br />Views (XAML + C#)<br />View Models<br />Application Services<br />Unity<br />Service Agent<br />Commands<br />DTOs<br />Command Service<br />Command Handlers<br />WCF<br />Domain Services<br />Mementos<br />Domain Model<br />Unity<br />Enterprise Library 5<br />NCQRS++<br />NSerivceBus<br />Events<br />Event Handlers<br />Event Bus<br />Domain Repository<br />Events<br />UoW<br />Event Store<br />Query Service<br />Denormalizers<br />WCF Data Services<br />Thin Data Access Layer<br />Entity Framework 4<br />SQL Server<br />Entity Framework 4<br />SQL Server<br />
    16. 16. NCQRS<br />The CQRS framework for .NET http://ncqrs.codeplex.com/<br />Very promising<br />Great Documentation<br />Quality code<br />Uses Code Contracts<br />Very active team<br />I’m considering joining <br />(Still) difficult to get started<br />Not proven yet<br />Not complete yet<br />Feels a bit too complex<br />Not everything is pluggable<br />Misses a coding standard<br />
    17. 17. In summary<br />Great for performance<br />Very scalable<br />Supports historical auditing<br />Supports high concurrency<br />Easy to integrate with other systems<br />Very testable with TDD/DDD<br />Aligns great with Ubiquitous Language<br />Doesn’t require expensive RDBMS<br />Lots of new concepts<br />Lots of choices to make<br />Not yet accepted by management<br />Limited documentation<br />No consensus yet<br />More complexity<br />Aggregate design is important<br />I haven’t found all issues yet<br />
    18. 18. Background InformationGreg Young, Mark Nijhof, Udi Dahan, Jonathan Oliver<br />Example Code, FrameworksThe CQRS Kitchen, NCQRS<br />Interaction Design / Task-Based UIsThe Inmates Are Running The Asylum, Alan CooperMicrosoft Inductive User Interface Guidelines<br />Links<br />
    19. 19. Emaildennis.doomen@avivasolutions.nl<br />Twitter<br />ddoomen<br />Blogwww.dennisdoomen.net<br />Questions?<br />

    ×