Monolith to Micro-Services? Event Sourcing Can Help

Please log in to watch this conference skillscast.

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.

YOU MAY ALSO LIKE:

• Surfing the Infinite Monkey Theorem for Fun and Profit (SkillsCast recorded in November 2017)
• Architecture to Create Culture (SkillsCast recorded in November 2017)