We explain the pros and cons of Event Sourcing compared to traditionally updating the current state in a database. We cover trade-offs with Eventual Consistency, problems with concurrency, and options to solve those with optimistic concurrency techniques.
Software architecture is often just about drawing boxes and arrows. It’s about designing fundamental structures and systems and how they relate to each other.
Microservices, a Modular Monolith, or a Big Ball of Mud. This video explains the pros and cons of choosing a distributed system over one big monolith (whether that’s a nicely structured Modular Monolith, or just a jumble of spaghetti code).
Bounded Contexts, subdomains and strategic design from Domain-Driven Design explained.
Explaining Aggregate Roots, Domain Events, Entities, Value Objects and Repositories - the building blocks in Domain-Driven Design.
Command-Query Separation and Command-Query Responsibility Segregation. Two design principles explained.
You’re probably familiar with the N-tier architecture. This video explains the Hexagonal, Onion and Clean architectures, and how they relate to each other.
A remote version of my Onion Architecture talk from DDD East Midlands with a few extra slides and alterations. Presented at a local evening meetup and streamed to YouTube.
When I think of a software system, I see shapes and lines connecting groups of smaller shapes and smaller lines. Like a galaxy of solar systems with planets of continents, each with roads connecting cities with villages and hamlets. It’s a structure that fits related concepts together and hides away complexity at different scales.
That’s what it all comes down to. Not to diminish anyone’s long, hardworking career, but every design decision we make ultimately boils down to where we want to define a certain boundary. What concepts should we couple together? Which layers “know of” which? It’s all a structure of how thoughts and ideas fit together.
At its core, Domain-Driven Design is about building shared models as a collaboration between domain experts and technical experts. When engineers speak the same language as the rest of the business, we can build an architecture that aligns with how the business works.
A lot of software engineering is about drawing boxes. That is, deciding how to break down the code we write. We don’t just write everything in the
Main method. We set boundaries, create abstractions, and divide things into single responsibilities.
Explaining how I reason about the building blocks of Onion Architecture, Domain-Driven Design and Command Query Responsibility Segregation in an event-driven microservices architecture. How it all fits together in my head, the concepts they share, and the mistakes I’ve made along the way.