Disclaimer: This blog post is my notes and interpretation on concepts and ideas presented in the book together with some reflections from my own experience working with various organizations.
I first heard about Domain Driven design a couple of years back but it took me quite a while to deep dive in the book “Domain Driven Design, Tackling complexity in the Heart of Software”. I guess better to be late at the party than never joining. The following series of post will be my personal notes on the book chapters together with concepts that are presented.
Why talk for Models & Domains ?
According to the Oxford Dictionary a domain is an area of knowledge or activity; especially one that somebody is responsible for. As developers our area of expertise is software and the technical challenges that it imposes. Respectively, we correlate the word model with databases, hardware, simulation etc.
Now days software has invaded most of the businesses and industries. The complexity of most of those software products lies on actually assisting the business domain by solving the problems using technical concepts and tools.
Domain Driven design approach introduced a new way of connecting software with the complex domains they assist and argues that the domain model “is the heart of the software”. For DDD the domain is the knowledge of the expert(s) simply organized and represented in selective abstractions. The sorted knowledge and chosen abstractions will be used by the software model to fulfill the needs of the domain industry. The software model should focus solely on the aspects of the domain that are needed and from the perspective that the knowledge is organized.
How to produce an effective Domain Model ?
An effective model is a representation of the problem’s solution that brings out only what is really important. For achieving it, Domain Driven Design introduces some new principles and terms:
Knowledge crunchers
Teams that are effective on creating a domain model consist of both software developers and domain experts, who are in the constant work of finding the abstractions that are most relevant. Most of the organizations and teams now days follow agile methodologies and develop on iterations, which helps to gradually build a software product. For building a useful product which is maintainable and extendable with powerful features developers need to plunge into the principles behind the product they build. In the opposite case or in a case of micromanagement of the team, the result is a Feature Factory and as John Cutler describes, many developers are “just sitting in the factory, cranking out features, and sending them down the line.”
Ubiquitous language
For people to crunch knowledge they need to communicate. In any kind of organization, most of the problems arise because collaborators get lost in the translation. It is rather common to attend meetings with business oriented people and software developers where each party describes requirements and actions using their own concepts and terms. At the end of those conversations there is a lack of common understatement and common goal. This leads to misunderstanding requirements, introducing software bugs and end up with bad quality of delivery and end user experience. In order to overcome the translation barrier, Domain Driven design introduces the Ubiquitous Language.
This language consists of:
- Vocabulary: names of the classes and some outstanding operations
- Conditions for expressing rules that apply in the model. This conditions are a set of technical and high-level organizing principles that are imposed to the model.
- The names of patterns that are being used and applied in the implementation of the domain model.
In other terms the language defines the types of entities, actions, and behaviors the user of the system can understand, and thus the way the software should be modeled. This language is used to facilitate the communication between technical people and domain experts and is not spread across the whole organization. It is not even common among the various technical teams that could exist in an organization.
The existence of a model language brings common concepts with a shared meaning. But the biggest benefit is that upgrades the model to not just be a technical artifact that leaves separately from the business domain but rather to go hand by hand with the domain’s evolution.
Binding the implementation with the model
Keeping the model relevant to the code and vise versa it is not a walk in the park of software engineering. The analysis, which captures the core concepts of the domain should not deviate from the design process, which specifies the set of programming components. For DDD the modeling and design process is a single iterative loop, which helps find the model that works well for both processes.
The book presents design and implementation patterns for code to express a model effectively and techniques on how to iteratively refine the model and the design.