Going in for agile make sure the game is worth...
DDD: A Brief Introduction into the ApproachStarting from 2004, when the term was introduced and developed by Eric Evans in his ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’ (known among the followers as the Blue Book), DDD has been attracting the attention of developers working with many different languages. PHP, Java, Python – the DDD approach is technology-agnostic: its benefits can be reaped with any target technology. As dddcommunity.org describes it, DDD is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
This definition gives three main characteristics, aka principles, of the DDD approach:
- Placing the project’s primary focus on the core business needs. That means that the product must solve end users’ problem, otherwise even its most well-planned structure will be useless. This is reflected in the name of the approach, which focuses on the notion of the ‘domain’, i.e. where the problem lies.
- Engineering complex designs based on a model. A model here is the focused knowledge around a particular problem that describes the selected aspects of a domain. Even the most complicated structure can be divided into certain subdomains, each presenting a separate problem, and this division incredibly helps single out and focus on each problem’s solution.
- Initiating a creative collaboration between technical and domain experts. The gap between tech experts and domain specialists is often cited as the major problem of software development: domain experts focus on delivering business value, while the attention of the development team is grabbed by the ways to find an optimal implementation scenario without a precise idea what this solution will bring for business. DDD initiates tighter collaboration between both teams. Ideally, this collaboration should take place not just at the preparatory stage, but continue through the project development, launch, and maintenance stages.
As a result, the implementation of this approach can bring about some much sought after benefits:
- The team, including the business and IT stakeholders, gets a common model which they can use to communicate: tech specialists understand business requirements of the project; the domain experts have a clear idea about data entities and process models;
- The model is easy to maintain as the design reflects the business model;
- Thanks to the modular structure, promoted by the DDD approach, business domain objects can be reused and tested.
The process of implementing the DDD approach to software development
- Working out the ubiquitous language. The notion of the ‘ubiquitous language’ is one of the central ones in DDD. It aims at establishing the same terminology which is used by the business and thus tightening the interaction between domain experts and software developers. Investing into a ubiquitous language helps reduce costs of translation, as all the parties involved will have the same definition of the terms (and situations with one party saying ‘account’ for a user ID and the other – for credit-debit papers, will be avoided).
The principal rule is: the ubiquitous language should be mirrored in the code.
- Breaking down the whole complex domain into subdomains of lesser complexity. The process of first identifying problem space and mapping them onto some picture (‘context mapping’) permits to separate different subdomains from each other in order to solve the problem of each subdomain in isolation. Identity and Access Management System or Project Management System can be examples of subdomains. One of the key DDD rules has it that each model can and should be dealt with independently of the others; the introduction of this boundary is what constitutes a ‘bounded context’, another key term for DDD, which represents a solution space. If distinguished correctly, bounded contexts usually look like products (a pricing strategy product, a shipping calculation product, a product recommendation engine product, etc.).
- Establishing well-defined connections between bounded contexts, i.e. interfaces. From the outside a subdomain looks like a black box, with other subdomains knowing nothing about its data and implementation, that’s why direct dependencies are highly unrecommended. But these subdomains still need to communicate with each other. In a DDD-driven project this communication passes exclusively in terms of their public APIs. For example: one bounded context can act as a regular client of another, sending commands and queries or being subscribed to events coming from it.
Managing System Complexity Through Its Layered StructureFor keeping the domain logic separate from the rest of the application and thus managing an increasing complexity of the code, Evans recommends his system of layers, including:
- User Interface (UI)/Presentation layer. The layer is responsible for displaying information to the user and accepting new data (for example, a voice-enabled service, views, languages, assets can lie in the UI layer). Following the DDD standard of dividing and categorizing data into separate subdomains, the key rule states: a radical change in UI should have minimal (or controlled, at least) impact on the rest of the system.
- Application layer. This layer defines the actions to be accomplished in order to solve the problem and coordinates these actions, representing a gateway to business logic with integrated transaction control. This layer has no business rules or knowledge and is typically kept thin. It usually contains Controller, Middleware, and Route.
- Domain layer. Here lies the business logic of the project that reflects and controls the business situation, with no infrastructure specific code. Entities, Model, Repository interfaces, Transformer, Policy, and domain services are stored here.
- Infrastructure layer. This one’s key responsibility is to provide generic technical capabilities to support the other layers and to persist data in order to keep the domain layer ‘clean’ from extra tech details. That’s why common service like Logging or Email are usually stored here.
- Focus on the DDD approach application. That is model objects need to be in line with the chosen domain and follow the ubiquitous language of the project;
- Staying true to the chosen framework. That means leveraging its power inside the domain.
Applying the DDD Principles: Scope of ProjectsGenerally, Domain Driven Design is considered as a perfect solution for years-long projects which are supposed to be evolving for years, where the costs of maintenance and expanding are higher than the cost of development. Usually DDD doesn’t apply to quite straightforward services or to short projects, where simpler approaches would be more cost-efficient. However, the benefits of the approach that promotes constant communication between tech specialists and domain experts, focuses on the value of the product for end-users, and puts the intricacies of the business domain at the core can work well for a web solution of any scale.
DDD is not about applying certain patterns to the project. Its most important part concerns organizing the code in order to make it aligned to business problems, and using for this the same business terms in the ubiquitous language clear for all the stockholders: business owners, domain experts, and technical specialists. The complexity of its implementation can be simply outweighed by the benefits of the adoption of years-long successful practices for a work process.