schedule Nov 29th 01:55 PM - 02:25 PM place State 3

As Culture Amp's product group grew (now 70 people) it became increasingly obvious that having a single monolith and single codebase was slowing us down, and creating single points of failure. This talk will cover how we embraced event sourcing as an architectural pattern to help us refactor the monolith - helping us to identify the boundaries of context - in preparation for identifying and harvesting appropriately scoped micro-services.

The rigid conventions of how aggregates can communicate forces you to think deeply about what your Aggregates are, what Commands they should accept and what Events they should emit. Enforcing that Aggregates cannot access the internal data of any other aggregates (of the same type or otherwise) forces you to think in terms of high cohesion / low coupling, and, when necessary, accessing projections - and by inference accessing an external representation of another context.

The standard architectural patterns for CQRS and event sourcing introduce an eventual consistency problem that needs to be understood and designed for - particularly in the UI. However, if you're migrating a monolith much of your UI was likely build assuming the page loads only occur after the database and views are updated. One of the advantages of starting event sourcing just within your monolith is that you can force the projections to be updated before returning success to a command. This has obvious down sides - namely impacting performance, stability, separation of concerns, and scalability, however as a stepping stone towards introducing event sourcing it's a fantastic way to allow you to focus on the Command side of CQRS initially without having to make any UI changes.

 
1 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

1. What is CQS and CQRS?
2. What is Event Sourcing?
3. Deep dive on how we identified our aggregates.
4. Which aggregate to start building out first? Top down, or bottom up?
5. The eventual consistency problem - exacerbated by legacy UI - and how we initially avoided it.
6. What does this architecture enable for us? How does it make it easier to break out micro-services?
7. Questions

Learning Outcome

That event sourcing and CQRS can be a powerful tool for helping you define boundaries of context, and decommission a monolith.

That although it's ideal to embrace eventual consistency, it is possible to avoid this - and thus avoid having to make UI changes upfront.

Target Audience

People either trying to work out how to break up a monolith, or embrace event sourcing.

Prerequisite

A strong understanding of software architecture, domain modelling, and working with distributed systems.

I plan to cover briefly the concepts of CSQRs and Event Sourcing to ensure I can bring as many people in the audience along with me, but those with deeper knowledge of those two topics are likely to get more out of the session.

schedule Submitted 3 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal