Is Shifting to Domain Driven Design worth your Efforts?

In our earlier blog, we explored a bit about Microservices. But let’s take a step back and look into how microservices can be effectively designed.
Yes, you guessed it right. We will be talking about the Domain Driven Design or what we call the DDD approach.

But before jumping into the concepts of Domain Driven Design, let’s understand 2 basic terminologies :

• Domain:
  A domain is the sphere of knowledge and activity around which the application logic revolves.
• Model :
  A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

Now that you know what a domain and a model are, let’s try to understand what Domain Driven Design is.

Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities, tasks, events, and data within a problem domain into the technology artifacts of a solution domain.

The emphasis of Domain Driven Design is to understand the problem domain in order to create an abstract model of the problem domain which can then be implemented in a particular set of technologies.

DDD focuses on three core principles:

• Focus on the core domain and domain logic
• Base complex designs on models of the domain.
• Constantly collaborate with domain experts, in order to improve the application model and resolve any emerging domain-related issues.

UNDERSTANDING THE UBIQUITOUS LANGUAGE

“ Translation blunts communication and makes knowledge crunching anemic.”

- Eric Evans

One of the problems many software development efforts face is the constant friction introduced by translation between two technical vocabularies, that of the business domain on the one hand and that of the developers on the other.
To some extent this duality is inevitable: developers must frame their work in terms of algorithms and computation, which generally have no direct equivalent in the business vocabulary. Thus comes a need for adopting a language policy that mitigates these difficulties.

The Ubiquitous language is defined as a language structured around the domain model and used by all team members to connect all the activities of the team with the software.
This language is about the business domain and uses terminology from the business domain — not IT technical terms.

BUILDING BLOCKS

Domain-driven design also defines a number of high-level concepts that can be used in conjunction with one another to create and modify domain models:

• Entity: An object that is identified by its consistent thread of continuity, as opposed to traditional objects, which are defined by their attributes.
• Value Object: An immutable (unchangeable) object that has attributes, but no distinct identity.
• Domain Event: An object that is used to record a discrete event related to model activity within the system. While all events within the system could be tracked, a domain event is only created for event types which the domain experts care about.
• Aggregate: A cluster of entities and value objects with defined boundaries around the group. Rather than allowing every single entity or value object to perform all actions on its own, the collective aggregate of items is assigned a singular aggregate root item. Now, external objects no longer have direct access to every individual entity or value object within the aggregate, but instead only have access to the single aggregate root item, and use that to pass along instructions to the group as a whole.
• Service: Essentially, a service is an operation or form of business logic that doesn’t naturally fit within the realm of objects. In other words, if some functionality must exist, but it cannot be related to an entity or value object, it’s probably a service.
• Repositories: Not be confused with common version control repositories, the DDD meaning of a repository is a service that uses a global interface to provide access to all entities and value objects that are within a particular aggregate collection.
• Factories: DDD suggests the use of a factory, which encapsulates the logic of creating complex objects and aggregates, ensuring that the client has no knowledge of the inner-workings of object manipulation.

Now that you have a basic knowledge of the building blocks of Domain Driven Design, Let us have a look at how the DDD process works.
The process of Domain-Driven Design involves collaboration between developers and non-developers. Ideally, there will be a shared model (which is a model that can be shared between a different Bounded Context) with shared languages so that as people from different domains with different perspectives discuss the solution, they have a shared knowledge base with shared concepts. The below diagram will help you understand better.

Navigation Map establishing the relationship between the components of Domain Driven Design

Why Do i need Domain Driven Design?

• Eases Communication:
  Generally speaking, DDD comes in quite helpful when it comes to helping the team creating a common model. The teams from the business’ side and from the developer’s side can then use this model to communicate about the business requirements, the data entities, and process models.
• Provides Flexibility:
  DDD turns around the concepts of object-oriented design. This implies that almost everything in the domain model is based on an object and therefore will be modular and encapsulated, enabling the system to be changed and improved regularly and continuously.
• Improved Patterns:
  Domain-Driven Design gives software developers the principles and patterns to solve tough problems in software and, at times, in business.
• Reduced Risk of Misunderstandings:
  Requirements are always explained from a domain perspective. Conceptualising the software system in terms of the business domain reduces the risk of misunderstandings between the domain experts and the development team. This also reduces the risk of ‘back-and-forth’ while freezing requirements.
• Better Team Coordination:
  The coordination is more people driven (since everyone is using the same terminology) that is less top driven, ensuring fewer bottlenecks.

These were some of the many advantages of the DDD design. But life is all about balance, Right? So along with the advantages there are some cons to DDD approach as well.

We will try to list down some of the disadvantages of the DDD approach as well :

• Additional Efforts Required:
  The main disadvantage of introducing DDD in software development is the additional effort required to adopt this software development approach. Additional effort and time is needed to create a substantial model of the business domain before positive effects on the development process become apparent.
• Requires Domain Experts:
  DDD projects require domain experts that are often expensive to hire, since they hold valuable knowledge.
• Only Suitable for Complex Applications:
  DDD was designed to simplify complexity. It is a great approach to software development if there is a need to simplify, but for simple applications, using the DDD is not worth the effort.
• High Encapsulation can be an issue:
  high level of isolation and encapsulation in domain model may present a challenge for business domain experts

Now, We hope that you have some idea about what Domain Driven Design focuses on .
To conclude, one can say that the DDD approach moves the focus from methodologies, tools and project management to the core of software system being developed and the expert domain it will engage with.

For more information, you can refer the Domain Driven Design By Eric Evans.

Hope this Helps. Stay tuned for more interesting articles. :)