Practical Domain-Driven Design with .NET
Domain-Driven Design, Clean Architecture, Vertical Slices, and SOLID in ASP.NET Core
Coming soon in paperback and Kindle.
About the book
Learning architecture twice
What you'll build
One system, every pattern it needs
By the end, you'll have built the foundation of a multi-tenant SaaS API and worked through one complete, representative example of each pattern, with the reasoning, the code, and the tests behind it.
- 01
Registering a student
- 02
Linking a guardian
- 03
Enrolling a student in a school
- 04
Adding a student to a section roster
- 05
Recording attendance
- 06
Posting grades
- 07
Notifying a family
- 08
Publishing an event to another system
What you'll learn
The reasons, not just the patterns
- Model business rules in a domain that protects itself.
- Organize the application by use case with vertical slices.
- Separate commands from queries, using EF Core where it helps and Dapper where it helps.
- Keep every tenant's data apart by default, not by remembering to.
- Authorize by capability instead of role name.
- Make domain events reliable with an outbox, and prove all of it with tests at every layer.
Who it's for
Written for three kinds of reader
If you're newer to architecture
You write C# comfortably and you've built an API or a web application. You've started to feel the pain architecture is supposed to solve, but you're not sure what the solutions are or when each one applies. Read front to back and build along as you go.
If you know the patterns by name
You've read about aggregates, repositories, and clean architecture, but you've never seen them all hold together in one system under real constraints. Skim the foundations, then read the middle of the book closely. That's where the decisions get made.
If you're an experienced architect
You've made these decisions before, and you want to see them made again with the reasons written down. Every chapter names the alternatives I weighed, so you can see where we differ and why. I expect you to disagree with some of my choices.
Inside the book
Twelve parts, twelve questions
Each part answers one architectural question, and each answer creates the need for the next.
- I
Foundations
Why does architecture matter, and where do we start?
- II
Modeling the Domain
What is the business, expressed in code?
- III
Use Cases and Vertical Slices
How does the application use the model?
- IV
Persisting the Write Model with EF Core
How do aggregates get stored, safely, without the domain noticing?
- V
The Read Side: CQRS with Dapper
How do screens get data without going through the write model?
- VI
The HTTP API
How does a set of working endpoints become an API that other people can build against?
- VII
Testing the Whole System
How do we know the whole system works, and keeps its shape, as it grows?
- VIII
Security and Multi-Tenancy
Who is calling, which district are they working in, what may they do, and how do we know one district can never see another's students?
- IX
Reacting to Change
How does the system react to change, inside itself and outside, without losing a reaction or doing one twice?
- X
Aggregate Design in Practice
With the whole architecture in place, what does each remaining core area need that we haven't met yet?
- XI
Production Readiness
What does the application itself have to do so that a district can run it, whoever hosts it?
- XII
Looking Back, Looking Forward
What is the one design under all of it, and how do you use it on a system of your own?
Built with
Current .NET, and only what it needs
- .NET 10 (LTS)
- ASP.NET Core Minimal APIs
- Entity Framework Core
- Dapper
- SQL Server
- xUnit
The book avoids dependencies that .NET already covers, and explains each one it does take where it's first used.
What it doesn't cover
Where the book stops
This isn't a book about hosting, deployment pipelines, containers, or cloud infrastructure. Those matter, but they differ from one organization to the next far more than the application does. Where the application's work ends and the host's begins, the book says so and stops.
Get in touch
Let's talk about software, architecture, or the book.
Whether it's a question about a chapter, an invitation to speak, or a design problem you're working through, I'd like to hear about it.
