Update
Due to unanticipated circumstances (a TBI from a head injury, it turns out), I have stopped work on the project. Thanks for your support and enthusiasm!
— Steven A. Lowe, March 15. 2020
The original page remains below for quasi-historical purposes.
You might be wondering:
Why Domain-Driven Design?
Domain-Driven Design (DDD) follows a simple yet elegant philosophy:
Software systems should reflect the most important elements of the real-world domain that they serve. Therefore the design of the software should be driven by what we know/learn about the domain.
This provides two benefits:
- When the real world changes, it is easier to see how the software systems should change in response.
- When we learn something about the domain from the software, the changes to the software can inform changes to the real world.
The harmony between the software and the real world allows learning to flow in both directions. The principles and practices of DDD flow from this philosophy, informing design options and decisions at all scales.
Why Head-First Domain-Driven Design?
This book’s approach to practical domain-driven design flows from three guidelines:
- Capture the model
- Embed it in the code
- Protect it from corruption.
These principles will help developers, analysts, and architects learn when and how to use DDD, including the technical and tactical knowledge to do just enough and do it well.
Is there a robot on the cover?
You mean, like this?
Sadly no, this is just a rejected mockup of an idea, one of many.
Can I get the book right now as a PDF file?
No, the book is a work-in-progress, slated for publication in 2019.
But you can get early access and news, and some PDFs on occasion.
Join the alpha/beta readers group using the form below to get Chapter 1 (draft) right away!