DDD Bounded Contexts & Subdomains
Bounded Contexts, subdomains and strategic design from Domain-Driven Design explained.
#agile
#analytics
#aop
#architecture
#ci-cd
#cqrs
#ddd
#decorator
#events
#firestorm
#jekyll
#logging
#meetings
#microservices
#platform
#refactoring
#rest-api
#speaking
#sre
#teams
#this
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.
DDD Building Blocks
Explaining Aggregate Roots, Domain Events, Entities, Value Objects and Repositories - the building blocks in Domain-Driven Design.
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.
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.
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.
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.