Leveraging Domain Driven Design in Your Projects

DDD is hailed by developers to be a perfect approach to large enterprise-scale projects with multiple entities and bounds between them. At the same time, its implementation on a project can be a tricky process. Which benefits can the DDD’s implementation bring and what are the possible pitfalls of trying to apply it?

DDD: A Brief Introduction into the Approach

Starting 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.).
The optimal solution is to align one problem space, i.e. Subdomain, with one solution space, i.e. Bounded Context. However, in the DDD system this most desirable outcome is not always achievable from the start. Say, a third-party system integrated into the software, has its own logic, which doesn’t always fit the DDD approach. Or the system development process was launched without DDD in mind, and now needs to be adapted to the changing rules. Correcting these inadequacies is another task to be tackled by a custom software development company when implementing DDD on the project, with no pre-defined silver bullet solutions to them.
  • 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.
Have any questions? Ask our team!
The messages between bounded contexts come in a form of commands (which represents a request that can be either accepted or rejected; if rejected, it leads to a change in a system) and events (which represent something that took place in the past, therefore considered as a statement of fact which can be used for taking decisions in other parts of the system).   

Managing System Complexity Through Its Layered Structure

For 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.
However, not every framework is fit for the DDD approach. So tech specialists need to find a solution meeting two requirements:
  • 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.
In some situations it is not always evident from the start how to meet both requirements. For example, Laravel ORM models are generally used both at the user’s representation level and at the data layer – which already breaks one of the key DDD principles. However, there are still ways to overcome this discrepancy, for example, with the value object pattern, i.e. defining the object solely by its attribute values. Here, at R-Style Lab, our Laravel developers would keep an ORM model at the infrastructure layer and connect to it from other layers via its attributes.

Applying the DDD Principles: Scope of Projects

Generally, 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.
Did you like our post?

Subscribe to our monthly IoT digest!

Please, enter a valid email address
Please, agree with our privacy policy

Check out services we provide!

Get a Free Quote Now!

Popular Posts

Link copied to clipboard

Get 3 bonuses now!

Just Share Your Project Idea
(We'll Keep It Safe!)
& Get Your Bonuses for Free!

get for free now