Domain-driven Design: Tackling Complexity in the Heart of Software [Review]
Oct 29, 2014
Table of contents:
Software development projects are notorious for failing in one way or another. This typically means that the project isn’t completed on time, it is over budget or it fails to meet the requirements of the end-user or organisation.
There are many possible reasons as to why projects fail and usually there is more than one contributing factor.
Domain Driven Design is a framework for tackling complex software projects to deliver an end-product that meets the goals of the organisation.
Domain Driven Design is not about any single technology. Instead Domain Driven Design promotes focusing the project on an evolving core model, and a collaborative feedback loop that concentrates on solving the organisation’s primary requirements.
Domain Driven Design is written by Eric Evans, a well respected consultant who helps companies navigate the troubling waters of building evolving software that is deeply connected to their business. Eric is a strong proponent of Agile Development and Extreme Programming and is highly regarded in the world of domain modelling and system design.
Why do projects fail?
Software projects fail for a whole host of reasons and so the circumstances around each project are usually so unique It can be difficult to predict where things might go wrong before its too late.
However I do think there are 4 common reasons why projects fail or play a part in the ultimate downfall of a project.
Lack of communication between the business experts and the developers
The first big problem is often a lack of communication between the business experts and the developers. When the requirements of the project are not clearly articulated or the business fails to invest in the project planning stage, it is inevitable that the application won’t meet their needs.
Developers fail to understand the problem they are solving
On the other hand, developers often fail to understand the project they are solving because they get too wrapped up in the technology or infrastructure of the project, and they do not invest enough effort to understand the organisation’s business requirements.
The code does not reflect the real world problem
When the requirements of the project are not fully articulated or understood, the code that is written often does not reflect the real world problem that is trying to be solved. This is evident when there are words or phrases in the code that do not match the definition of the world of the business.
Unable to refactor the code
And finally, it’s impossible to fully appreciate the design of an application at the very start of the project. As a developer you probably won’t fully understand the problem until near the end of the project.
It is therefore extremely important that the code you write should be consistently refactored in an iterative approach. Code that is tightly coupled, brittle or difficult to change will make the inevitable refactoring process much more difficult than it needs to be.
What is Domain Driven Design?
Domain Driven Design is a framework for approaching complex software projects by placing emphasis on the core model of the problem at the heart of the implementation.
Domain Driven Design also teaches you how to effectively model the real world in code and use the inherent power of Object Orientated Programming to encapsulate the business logic of the organisation.
An important part of Domain Driven Design is a set of patterns and common terminology. Domain Driven Design isn’t about a specific technology or programming language and so these patterns, terminology and tools encompass a theoretical workflow and not a concrete implementation.
Domain Driven Design puts a lot of emphasis on the ongoing collaborative nature of a software project. The solution to the problem is discovered through direct communication and modelling of the problem between the business experts and the development team.
This iterative approach aims to reduce the feedback loop in order to increase the suitability of the solution to the problem.
About the book
If you are new to the idea of Domain Driven Design, there is a lot to learn in this book. If you have already been practising Object Orientated Programming in non-trivial software applications, you will probably find that parts of this book put into words many of the solutions you might already know.
One of the most prominent lessons of the book is the importance of the ubiquitous language, and how integral communication between the business experts and the development team is.
The ubiquitous language should capture the business domain of the application and allow everyone who is working on the project to talk about the project using a shared vocabulary. Non-technical members of the team should understand the code that is written, and all technical members of the team should fully understand the inner workings of the business.
The book also introduces a number of design patterns and methods that encourage good Object Orientated Programming and make the inevitable refactoring process easier.
Whilst each software project will be different, there are many common tools and patterns that can be reused between each project.
And finally the book also teaches you how to model the complex requirements of a business in code. Often the first pass at a problem will produce code that does not fully meet the requirements of the business. I think one of the most important qualities of this book shows how this should not be an overnight process, but instead effectively modelling a problem will take a serious investment from both sides of the project.
Conclusion
The profound realisation that I found in reading Domain Driven Design is that it made me think of software projects in a whole new light. Previously I would of been intimidated to try and tackle a really big, gnarly enterprise application development project.
However this book shows you that complex or difficult problems can actually be very logical with clean and elegant solutions as long as you make the investment to really understand the problem from the perspective of the business expert or end-user.
A lot of the patterns, terminology and tools that I’ve been covering in my “Building Cribbb” series are taken directly from this book. Understanding these patterns and tools will not only enable you to implement the Domain Driven Design theory, they will also make you a much better Object Orientated developer.
I think if you are a fairly well experienced developer, this book will be a revelation for you. You might already be familiar with a lot of the code examples, design patterns and terminology that can be found in the book. However, I think the big take away is really the emphasis on the Ubiquitous Language, the importance of communication and how to effectively become a project leader, and not just an individual contributor.
If you are new to the idea of Object Orientated Programming, developing web applications or building websites in general, this book will probably be too much for you.
However, I would definitely add it your reading list. I think there is a lot to learn for all ranges of developer experience.
Domain-driven Design: Tackling Complexity in the Heart of Software on Amazon (Affiliate link)
