Domain Driven Design
Tackling Complexity in the Heart of Software
by Eric Evans
A fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing.
Software Developers tend to pay for attention to the hard skills, when it comes to software development. There is a tendency to focus on the features and implementation details of the Software Development languages and frameworks and just simply trying to solve problems.
When working on larger projects or in software development teams we may learn about concepts such as the Repository Pattern and Model Driven Design and may even implement Software Design Patterns and take an interest in Patterns of Enterprise Application Architecture. We may even start to dabble with developing Micro-services.
For many developers out in the field, it's highly likely they are actually implementing the concepts presented in Domain Driven Design, without explicitly knowing about it. Especially if you're working on any project that may have elements of microservices, because fundamentally Microservices are nothing more than Domain Services.
Why I read this book
Although this book was originally published in 2004, I only got round to reading it the first time circa 2009 when it was recommended to me by a colleague at the time. We were working on a project that was starting to implement some form of Service Oriented Architecture (SOA) and Microservices. We making use of Microsoft Biztalk and the then much maligned Entity Framework and it was the first time I was encountering the Repository Pattern and the Unit of Work and although I was familiar with Martin Fowlers work at the time, my colleague kept of referring to Bounded Contexts, Value Objects , Intention Revealing Interfaces and even ubiquitous language.
My colleague informed that after reading the book, it completely transformed the way he thought about software development and the implementation detail.
What I learned from this book
Domain Driven Design has 3 core tenets:
- The Domain Model - The heart of the system design
- Ubiquitous Language (UL) - A common language and words used by all team members, technical as well as non-technical. The UL is used in diagrams, in documents, in code and in speech. It must not contain any inconsistencies or ambiguity. A change in the UL is results in a change in the domain model.
- Collaboration between technical and domain experts is crucial to creating an application model that will solve particular domain problems.
Although the book is predominantly about writing software, you'll actually find very few Code Samples within the book and the concentrates on weaving the business realities with software development considerations. The core focus of the book for the most part, is not actually targeted solely at software developers, but mostly towards the entire multi-disciplinary team.
Domain Modelling
The first part of the book is primarily targeted towards how to put the Domain Model to work and the importance of gaining Domain Knowledge. The model of a domain doesn’t need to be realistic or concrete. Its only purpose is to solve the current use cases. As you add more use cases and you gain more knowledge, you should refine and improve the model. Also, this section introduces the concept of the Ubiquitous Language.
To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
Model-Driven Design
The second part of the book delves into the Building Blocks of a Model-Driven Design. By emphasising the importance of isolating the domain. Enabling the decoupling of the domain from other concerns like User Interface, Business Logic, Data Access, Database and infrastructure, using a layered architecture.
Why I recommend this book
Domain-driven design is a software engineering approach to solving a specific domain model. The solution circles around the business model by connecting execution to the key business principles.
Common terminology between the domain experts and the development team includes domain logic, subdomains, bounded contexts, context maps, domain models, and ubiquitous language as a way of collaborating and improving the application model and solving any domain-related challenges.
Many aspects of what we perceive to be Modern Software Development strategies, actually have their foundations in this book and its well worth taking the time to read this book to gain an understanding of their foundational layers.
- What is this Directory.Packages.props file all about? - January 25, 2024
- How to add Tailwind CSS to Blazor website - November 20, 2023
- How to deploy a Blazor site to Netlify - November 17, 2023