Recently, I have come across one of my clients where there was a big advocate for Domain-Driven Design (DDD). The DDD among the other SOA principles was one of the popular choices that attracted many large-scale digital transformation projects. As a famous quote, there is no silver bullet to address all the issues. Before jumping to a conclusion, I would suggest having a review of the Domain-Driven design principle.

The first time this term has been coined was by Evan Evans which is in essence an extension of Object-Oriented design where it aims at creating software abrasions named Domain Models. The idea is that this abstraction tends to help the developers who are not experts in the domain context. Ok, now one might question what is the domain object?

Domain Objects
Domain objects are anything that you work with, usually an area of knowledge or expertise. In short, the domain represents anything that you want to model. The enterprise application requires a complex relationship across various entities, this abstraction would become handy and useful as this complexity would make the modelling a tedious task.

Another element talked about in the DDD is the ubiquitous language. Ok, another jargon, basically, the ubiquitous language is the language understood by everyone (one of that generalisation, perhaps by. perfectionists). Okay, this is too vague, but let’s put it this way this is the language or terminology used by the common users of the system.

Common jargon’s for the DDD

Context: The setting or the line of business the domain is discussed. Such as Shipping, Education or Lending. This is the zone that a domain is modelled and explained.

Model: A way to illustrate a domain and it’s interaction with object domains in the same context. You can use UML but ultimately any system which would work.

Ubiquitious Language: A language understood by the developer and the subject matter experts in the business context.

Out of the top items, the domain and the language tend to reduce the complexity of explaining how different domain objects are related. During this process, don’t be afraid of suggesting new names as this process tend to be iterative. That’s it, no big bang approach, small pieces.

Building Blocks

The DDD is based around the followings

• Entity
• Value Object which has no identifier
• Aggrgate: groups the entities and the value objects
• Service
• Repository : this would be similar to the Services in the Spring Boot
• Factory: the same factory pattern for constructing complex entities or value objects