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):
- 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.
- 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.
- 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.