What is Domain-Driven Design
Domain-Driven Design is a software technique, an approach for the development of large complex applications. It was introduced by Eric Evans in his book 'DomainDomain-Driven Design: Tackling Complexity in the Heart of Software”.
Domain-Driven Design puts core domain and domain logic in the center of our software. Our business logic should be agnostic to frameworks, databases and other technical tools. It includes concepts like: Bounded Context, Domain Model and Ubiquitous language.
Domain-Driven Design is about making your software close to the real world process and system. It requires close collaboration between developer and domain expert. Domain expert is a specialist of the peculiar area of interest. For example, if we create medical software we would need a medical doctor on the other hand if we are in fintech we would need an expert in Economy. Most important part is communication between those two positions. A Programmer has to understand business people and their point of view.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Refactoring: Improving the Design of Existing Code, 1999
Programer and domain expert build Ubiquitous language that allows them better communication". Idea is that programmer writes a system in a way that domain expert can understand and it’s capable of verifying if it is correct. They together create Domain model.
When we talk about the model it is always in some context. Large software has a large model that we need to divide in bounded context. For example different company departments (sales, transport, marketing, support…) has a different perspective of the product. For them product is used in different context.
Architecture
For the programming perspective DDD also represents implementing OOP, SOLID principles, design patterns, TDD (Test Driven Development) and other best practises...
In Evans DDD book he introduced layered architecture intending to divides and isolates domain layers from application and infrastructure.
It’s recommended four layers:
• Presentation
• Applications layer
• Domain layer
• Infrastructural
Presentation layer is the user interface. User could be a real human or another computer. It should interpret user commands and allow communication with applications.
Applications layer is responsible for high level logic. It does not have business logic and we have to keep it thin. It should be use case and coordinate domain objects.
Domain layer model business logic of your application. It’s meter to business rules and it’s the most important part of your software that should not depend on frameworks and tools. It's the heart of your software.
Infrastructural layer is responsible for communication, storing data, providing data and services...
Domain-Driven Design benefits
The goal of Domain-Driven Design is to free business logic and domain code from the technical details and become framework and technologies agnostic, It’s business orintented.
Domain-Driven Design ensures good communication because encourages the use of “Ubiquitous language” which will improve communication between developers and business people.
It is suitable for large applications that never ends (software should follow business) also to save old legacy apps.
It requires more effort and higher costs at first and requires greater developers knowledge. Due to this it’s not recommended for small, short terms apps and under-proven teams. But with a good team it’s easy to handle any complexity.
Also Important is that we get better code easier to maintain. Clean, more readable and code covered with tests which ensure better reliability.
Further Reading:
• Eric Evans - Domain-Driven Design: Tackling Complexity in the Heart of Software.
• Vaughn Vernon - Implementing Domain-Driven Design (red book)
• Vaughn Vernon - Domain-Driven Design Distilled
Let's start{code}