Commands vs Events
Communication over a message bus is often done with Commands and Events. But, what’s the difference between them? Aren’t they both just messages?
#agile
#analytics
#aop
#architecture
#ci-cd
#cqrs
#ddd
#decorator
#events
#firestorm
#jekyll
#logging
#meetings
#microservices
#platform
#refactoring
#rest-api
#speaking
#sre
#teams
#this
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.
Transactional Outbox Pattern
The Transactional Outbox Pattern ensures a message is always published to a message broker when making changes to a database, even if the message broker fails initially. This is essential for event-driven architecture to ensure consistency when other services are rebuilding state from your events.
Conway's Law
The communication structures in your organisation influence your software architecture. We explore some examples of this and explain how it relates to Domain-Driven Design (DDD) and Microservices.
Event Sourcing
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.
Microservices vs Monolithic Architecture
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).
DDD Bounded Contexts & Subdomains
Bounded Contexts, subdomains and strategic design from Domain-Driven Design explained.
DDD Building Blocks
Explaining Aggregate Roots, Domain Events, Entities, Value Objects and Repositories - the building blocks in Domain-Driven Design.
CQS and CQRS
Command-Query Separation and Command-Query Responsibility Segregation. Two design principles explained.
Hexagonal, Onion & Clean Architecture
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.
Onion Architecture (Remote)
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.
Visualising Software in Shapes
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.
Software is about Drawing Boxes
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.
Domain-Driven Boundaries
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.
Onion Architecture with DDD and CQRS
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.
Onion Architecture with DDD and CQRS
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.