Domain-Driven Design focuses on the modelling software around a business domain by collaborating with experts in the domain.

The structure of the code should match that of the domain model, and the language used in the code should be written in a defined Ubiquitous Language that is spoken by both technical and domain experts.

The Building Blocks of 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.

Read More

Domain Events vs Integration Events

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.

Read More

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.

Read More

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.

Watch Online