Design Engineering-II-DDD-Domain Driven Design

The field of Software development is inundated with myriad of concepts, terms, phrases, philosophies, approaches like no other field and it never falls short of any. This is always confusing to anyone & everyone and it results into different personnel's having different perception of such concepts and no wonder, it creates implementations which are mostly not aligned to fundamental & core concept. In such situations, the anticipated benefits of following certain philosophies doesn't materialize to fullest potential and in the event, there are doubts raised about the merit of such philosophies, approach's etc. when the onus is not understanding the concepts well enough i.e. issues with conceptual integrity.

DDD- Domain Drive Design is one such approach which is grossly misunderstood and at the same time, still creating paradox in the minds of practitioners.

What's DDD?

Its an approach in software development which advocates centering the software development on programming model which carries rich understanding of processes and rules of a domain for which software is programmed for. It also implies that focus of software modelling shall be on matching to real business domain. It opposes the idea of having a single unified model for entire system. Rather it divides the entire system into bounded contexts each of which their own model and how these bounded context interact with each other.

This term was coined by from Eric Evan in the year 2003 through the book "Domain-Driven Design: Tackling Complexity in the Heart of Software".

What's the DDD practice?

The practice is collection of concepts, strategies, patterns and tools that help design software system based on DDD approach and manage the complexities often the messy logic, well enough.

DDD Key concepts/ building blocks

"Domain" is the subject area which a software program applied for, of course by the users of the program.

"Domain Model" is an artifact which is made of abstractions of selected aspects & characteristics of the domain and also used to solve the targeted problems in that domain.

Ubiquitous Language

One of the important core concept of DDD approach is to strive for using the vocabulary of he the business domain and using it through the requirements to design to software's source code itself. So essentially its a language built to be shared by the domain experts, dev team and other stakeholders.

Characteristics of the Ubiquitous Language

• Ubiquitous Language must be expressed in the Domain Model.
• Ubiquitous Language unites the people of the project team and eliminates inaccuracies and contradictions from domain experts & business stakeholders.
• Ubiquitous Language is not a business language imposed by domain experts and its also not a language used in business domain or industries.
• Ubiquitous Language always evolves over time, it is not defined entirely in a single discussion or meeting.

Entities

In the real-world scenarios, thee are peculiar objects which has unique identity. These objects are termed as entities in dolman model. Their unique identity don't change through the state transitions of the software. An entity encapsulates both the state and behavior. A good example is "Customer" entity whose identity remains persistent irrespective of changes in their name address or other attributes.

Value Objects

On the contrary, there are objects which are denoted by their attributes rather than unique identity. These are immutable which means their state can't be changed. Good examples are monetary values,. data ranges, addresses etc. Their state remains he same as it was at the time of their creation. These could be easily replaced with another instance having same attributes without triggering any change in the state of the system.

Bounded Contexts

Bounded contexts facilitate logical boundaries to be defined in the system where a particular domain model applies. Generally any complex domain will have different categories and groups of objects and such group or categories formulate the bounded context

Aggregates

In the real world entities and value objects always have some form of relationship and/or dependencies. A cluster of such associated and grouped entities and value objects is named as an aggregate and are treated as single unit. The reference to such aggregate are confined to one member of the aggregate which is a root entity known as aggregate root. Certain consistency rules applies within the boundaries and aggregates maintain the integrity ensuring that changes to the the cluster remain coherent and stick to domain's rule and invariants.

Characteristics of the Ubiquitous Language

• Ubiquitous Language must be expressed in the Domain Model.
• Ubiquitous Language unites the people of the project team.
• Ubiquitous Language eliminates inaccuracies and contradictions from domain experts.
• Ubiquitous Language is not a business language imposed by domain experts.
• Ubiquitous Language is not a language used in industries.
• Ubiquitous Language evolves over time, it is not defined entirely in a single meeting.
• Concepts that are not part of the Ubiquitous Language should be rejected.

Any the business domain is characterized by events and few of these events hold significance and generally trigger actions in various parts of the system. These events also trigger state changes.

DDD Process

Here is a typical DDD process as described below graphic.

This objective of this writeup is to give a jumpstart to the readers who wish to know this approach and its key concepts and building blocks.

So far so good.

Happy Designing!!