Software Engineer
Domain-Driven Design focuses on the modelling software around a business domain by collaborating with experts in the domain.
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.
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.
When learning DDD, it's easy for us engineers to get caught up in all the technical jargon: "Aggregate Roots", "Domain Events", etc. Fundamentally though, Domain-Driven design is not about the technical details; it's about creating a model and language that the business experts share with the technical experts (the software engineers). It is, perhaps ironically, about not using technical jargon.
There are different kinds of events found in event-driven systems. They often represent the same thing that has happened, but serve different purposes and have different advantages. Here I'd like to outline the differences between a few terms.
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.