Domain Driven Design

Domain Driven Design
Domain Driven Design

I am sure you have all read this book and this book needs no further introduction – Domain Driven Design by Eric Evans! I readed this book couple of months ago and now I am trying to apply good ideas I got from this book. Instead of writing usual introduction I tell you a little bit about my experiences when applying ideas represented in this book.

Before I start I mention quickly that Domain Driven Design has only few code examples. To be honest I expected more but this is not a problem – there are many other books that cover design practices on more technical level. Most of this book describes ideas about systems architecture and design. It covers smaller systems and also larger systems that are built by separate teams maybe even in separate geographic locations. The mind framework this book gives is mighty. At least for me. Although first chapters of this book are a little bit dry and boring the further is very interesting. So, survive the first chapters and read this book to the last page.

After reading Domain Driven Design we tried to apply new knowledge in one of our systems we are building currently. There are some points that work very well (don’t repeat me if you haven’t read this book):

  1. Using services layer is very good approach because it keeps repositories clean of complex logic behind services. If services layer is not small then it is good idea to separate services and repositories.
  2. Using infrastructure layer is also good approach because this is the way how to keep different base services in separate library that is easy to switch to other if there is a need for it.
  3. Driving communication between subdomains only through subdomain’s main objects gives another advantage: it makes communication flow between objects very clear. There are less grey spots of responsibility and therefore less ways how to break things.

Of course, there are many other good points you can find from this book when you read it. Three points above gave just an example about how to apply Eric’s ideas.

Table of contents

Part I. Putting the Domain Model to Work
1. Crunching Knowledge
2. Communication and the Use of Language
3. Binding Model and Implementation
Part II. The Building Blocks of a Model-Driven Design
4. Isolating the Domain
5. A Model Expressed in Software
6. The Life Cycle of a Domain Object
7. An Extended Example: Using the Language
Part III. Refactoring Toward Deeper Insight
8. Breakthrough
9. Making Implicit Concepts Explicit
10. Supple Design
11. Applying Analysis Patterns
12. Relating Design Patterns to the Model
13. Bringing the Pieces Together
Part IV. Strategic Design
14. Maintaining Model Integrity
15. Distillation
16. Large-Scale Structure
17. Bringing the Strategy Together
Appendix. The Use of Patterns in This Book

Serverless360 Logo

A portal focused on Operations and Support for Microsoft Azure Serverless services


Gunnar Peipman

Gunnar Peipman is ASP.NET, Azure and SharePoint fan, Estonian Microsoft user group leader, blogger, conference speaker, teacher, and tech maniac. Since 2008 he is Microsoft MVP specialized on ASP.NET.

    One thought on “Domain Driven Design

    Leave a Reply

    Your email address will not be published. Required fields are marked *