Domain-Driven Design Introductory
Overview
When a team or organisation wants to fulfil business requirements by producing a software, many factors and features , such as architecture, technology stack, team topology and so on, should be taken into account.
But the mentioned factors are not the only parameters in designing a software to achieve our business goal and apply business justification in production.
Since I started to work as a software developer, in kind of all projects and all the companies that I have worked with them, Domain-Driven Design was one of the most challenging theme.
Nowadays, Domain-Driven Design is an inevitable subject in software production procedure and underestimating or eliminating this concept from software delivery lifecycle and generally from companies' workflow could be expensive and even cause to fail the project.
In this article series, I would gladly share with you my knowledge, experiences and lessons-learned in the field of Domain-Driven Design in software engineering and development, the necessity of Domain-Driven Design and how/why to use it to have a better outcome and company success.
What is Domain-Driven Design?
Domain-Driven Design is a set of tools that helps organizations (architects, developers and domain experts) to design a high-quality software. In other words, Domain-Driven Design is a software development approach that guides us to not to repeat our failures in designing software by putting the “Effective communication” between parties as the core principle.
As Vaughn Vernon mentioned in his book:
Domain-Driven Design is not first and foremost about the technology. In its most central principles, DDD is about discussion, listening, understanding, discovery and business value, all in an effort to centralized knowledge.
What important to remember is that not all the projects need the DDD. We have to always think about the expenses of Domain-Driven Design and its usage for our project.
As a matter of fact, we have to use it to simplify our solution not to make it more complex.
To accept and implement DDD methodology, we should be eager to improve the software and have skills to explore design alternatives using proven agile methodologies. Domain-Driven Design can be categorized in two main groups:
The second law of Software Architecture that is mentioned in Fundamentals of Software Architecture, by Mark Richards and Neal Ford, emphasizes that Why is more important than How.
Domain-Driven Design tries to cover both “Why” with Strategic Design and “How” mostly with Tactical Design. It means, with DDD not only we can cover the architectural patterns and definitions, but also implementation and design challenges.
This methodology helps us to create the domain model, that domain is the business problem and model is the solution to the problem, as one of the other reasons of doing DDD properly. Each assembled domain model should be mapped to the technical architecture (frameworks, programming languages, …) to satisfy the business requirements accordingly.
In the upcoming sections, I would explain the two mentioned categories in details to cover the topics below:
- Ubiquitous Language
- Bounded Context
- Domains and Subdomains
- Context Map
- Architectural Patterns (Domain Model, Active Record, …)
- Aggregates
- Entity
- Value Object
- Domain Events
Suggested Resources and References
There are many valuable books and impressive articles in the field of Domain-Driven Design in the market that are written by technology experts and experienced software architects.
The books that helped me significantly in my journey to learn this topic and use them in my daily workflow as a software architect are listed below. Furthermore, the mentioned books in the following are used as my references in these article series.
- Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy, By: Vlad Khononov
- Implementing Domain-Driven Design, By: Vaughn Vernon
- Domain-Driven Design Distilled, By: Vaughn Vernon
