What I’ve learnt (so far) – Daniel Wagstaff, 2020
Compiled from a year’s research into event sourcing and microservices, Daniel has pulled together a series of four videos to share key learnings suitable for experienced developers. During his research, he found that a lot of information was misleading, so this series of videos pulls together the best advice gathered from sources he came to trust – and has since tested.
Who’s this for?
- Most valuable to developers with at least three years’ experience, technical leads and software architects.
- Anyone who’s designing a system that is complex enough to warrant considering microservices.
What am I trying to achieve?
- After I researched microservices architecture and event sourcing (which is often used in a microservices architecture – sometimes when it shouldn’t be), I tried to distil the knowledge gathered.
- So, it’s a consolidated set of learnings about designing microservices based systems and applying event sourcing.
A four part series of webcasts
Part 1 – CQRS:
The foundation of event sourcing. It aims to explain when the design pattern, CQRS, should be applied and sets the context for talking about distributed systems.
Part 2 – Event sourcing:
Defines the difference between traditional data storage and event sourcing. Describes a typical use case and a common example of how to architect an event sourcing solution.
Part 3 – Typical architecture and concurrency:
Builds on the previous presentation’s example and addresses a common pitfall (concurrency in event sourced systems)
Part 4 – In practice (and Choreography vs. Orchestration):
Applies the concepts from the previous presentations to a real-world example, to reinforce the learning, plus addresses one more typical concern when designing microservices (Choreography vs. Orchestration)
A highly motivated and enthusiastic senior software engineer and Technical Architect, who is always keen to expand his technical knowledge and improve the solutions he delivers. He enjoys working with customers to discover their requirements collaboratively and iteratively building an appropriate and valued solution that is performant and intuitive. Daniel has often been recognised for his diligence when designing, creating and testing software.
His proudest moment as a software engineer? When a Triad software development client smiled and said, “This is exactly how I imagined it”.