Skip to content
Keshwar White
Coming soon

Practical Domain-Driven Design with .NET

Domain-Driven Design, Clean Architecture, Vertical Slices, and SOLID in ASP.NET Core

by Keshwar White

Coming soon in paperback and Kindle.

About the book

Learning architecture twice

Most of what I learned about software architecture, I learned twice. The first time was from books and articles. The second time was from building systems that people depended on, and finding out which of those ideas held up when the requirements were real, the deadlines were real, and somebody had to maintain the code after I'd moved on to the next problem.

This book teaches Domain-Driven Design, Clean Architecture, vertical slices, and the SOLID principles the second way, without making you wait years for it. It follows one example system, a multi-tenant student information system, from the first commit to an application that's ready to operate. One running system serves many school districts, and each district's data has to stay its own. So every pattern has to earn its place against realistic constraints.

Every pattern arrives with the problem it solves, stated first, in plain language. The code builds and runs, and the rules have tests. Where a first design turned out to be wrong, and several did, the book shows the mistake and what fixed it. I think you'll learn more from those moments than from the designs that worked the first time.

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.

  1. 01

    Registering a student

  2. 02

    Linking a guardian

  3. 03

    Enrolling a student in a school

  4. 04

    Adding a student to a section roster

  5. 05

    Recording attendance

  6. 06

    Posting grades

  7. 07

    Notifying a family

  8. 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.

  1. I

    Foundations

    Why does architecture matter, and where do we start?

  2. II

    Modeling the Domain

    What is the business, expressed in code?

  3. III

    Use Cases and Vertical Slices

    How does the application use the model?

  4. IV

    Persisting the Write Model with EF Core

    How do aggregates get stored, safely, without the domain noticing?

  5. V

    The Read Side: CQRS with Dapper

    How do screens get data without going through the write model?

  6. VI

    The HTTP API

    How does a set of working endpoints become an API that other people can build against?

  7. VII

    Testing the Whole System

    How do we know the whole system works, and keeps its shape, as it grows?

  8. 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?

  9. IX

    Reacting to Change

    How does the system react to change, inside itself and outside, without losing a reaction or doing one twice?

  10. X

    Aggregate Design in Practice

    With the whole architecture in place, what does each remaining core area need that we haven't met yet?

  11. XI

    Production Readiness

    What does the application itself have to do so that a district can run it, whoever hosts it?

  12. 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.