Software Engineer
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.
This is a story about how our team at Stack Overflow split out a small feature from a monolithic application into its own microservice. We moved the data to a new database, rebuilt the UI as a microfrontend using a new framework, and managed to deploy it without any downtime.
Different boundaries in a software system come with different trade-offs to consider. Let's zoom out from functions to distributed systems and look at what encapsulation means at each level.
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?
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.
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.
Deciding which things belong in which part of your system can make or break your architecture. To avoid creating a big ball of mud, we separate concerns and keep things organised. This talk takes us through different kinds of boundaries: What makes a good function? What makes a good class? A good service? We’ll discuss slicing vertically, building separate packages, and the trade-offs of splitting into many git repositories.
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, 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.
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.