I read Domain Driven Design (referred to in the following as DDD) by Eric Evans so you don’t have to! And you probably shouldn’t read it regardless. DDD is a really ambitious book trying to establish a right way to develop software but it, unfortunately, falls short.
I want software engineering books to improve my engineering, but following the framework described in DDD directly will lead to a dogmatism that will not be flexible enough to solve problems as they arise. Evans believes that logic related to the technical infrastructure should be totally segregated from logic related to the technical domain. I can see how that segregation can improve the clarity of the code, but realistically there will be many situations where the technical infrastructure is a very important consideration and should be included directly in the domain logic. Evans talks multiple times in DDD about performance issues that can arise from repository patterns, but he does not really discuss how to avoid those issues. He does not seem to recognize that technical infrastructure needs to be an early consideration in any software design. Sometimes a technical limitation is an important part of a domain. It seems like following the principles in DDD directly could lead to a design that cannot be implemented on any existing technical infrastructure and that is a big flaw.
Evans seems convinced that great software can be the difference between project success and failure. But in my experience, that is not typically the case and that is not the case in some of the examples Evans gives toward the end of DDD. Great software is unlikely to save an unhealthy organization and poor software is unlikely to poison a healthy organization. Great software cannot save a poor product and poor software (that works) is unlikely to sink a great product. If all you have is a pipe and you really need a hammer, you will be surprised how well the pipe works as a hammer. If you have a really nice hammer but what you need is a screwdriver then you would have been happier with a drill than you are with your nice hammer.
A really great product can be sold before it is built. A good product serves the needs of its customers effectively and if the value of the product is high enough the customers will make that clear. Evans talks about tight partnerships between engineers and domain experts, but really it should be about tight partnerships between engineers and customers. Customers don’t need to be (domain) experts, they just need to have problems. The real difficulty of making a great product is deciding who the customers are and what problems you are and are not solving. If you have a good product, lots of people will show up thinking they are your customer, but you will need to turn some of them away and that is very difficult.
I did not enjoy the style of DDD. It was very long and did not feel information-dense. Evans references many design patterns and principles but does not go into depth on how they work (partly because he extensively references other books). Given that DDD is set up as a very high-level framework for engineering, I think the book should have been much shorter with fewer references to specific design patterns and principles.
Despite the book’s significant shortcomings, it shows glimpses of really interesting ideas. I could be interested in a book that applies the idea of DDD to organizations instead of to code. DDD could have been about how organizations can maximize the value of software instead of about how to do software engineering. If an organization is willing to allow itself to be transformed by engineers implementing DDD, there can be many benefits including the ability for anyone in the organization to communicate effectively using the ubiquitous language. This means the CEO can talk directly to engineers about the domain using the same ubiquitous language. It also means managers can talk to sales representatives about the domain using the same ubiquitous language. The ubiquitous language has the potential to transform communication in an organization in a truly profound way.
DDD shows glimpses of providing good career guidance to engineers. Engineers looking to progress in their careers should be looking for the highest impact areas to contribute. Those areas are often in the core domain so being able to identify where the core domain problems lie can guide the types of projects ambitious engineers should seek out.
I really appreciate the ambition of DDD and it introduces some very interesting concepts. Ultimately I did not find it useful at a conceptual level or a practical level. For engineers looking to improve their skills, I would instead recommend A Philosophy of Software Design by John Ousterhout. Ousterhout’s framework of complexity encapsulation is truly flexible and has clear, comprehensible grounding with obvious opportunities for application.
Leave a Reply