Domain Driven Design

Domain Driven Design was proposed by Eric Evan in his book, ‘’Domain Driven Design: Tackling complexity in the heart of software ’’. It is a software development technique, which includes strategic, philosophical, tactical, and technical elements which are related to specific practices. The aim of Domain Driven Design is to ease out the development of complex applications by connecting the pieces of software in an evolving model.

The concept of Domain Driven Design works on three principles:

1. To focus on domain logic and core domain and embed the domain terminology in the code.
2. Complex designs are based on domain models. The aim is to protect the knowledge of the domain from corruption by other domains.
3. To collaborate constantly with domain experts for improving application model and solving any domain-related problems. Moreover, talking to other people in the same business and understanding their point of view is vital and this is how the ubiquitous language can be formed which sets a foundation for harmonious models.

The above mentioned principles guide Domain Driven Design and their use provides benefits.

The following terms are used when Domain Driven Design practices are discussed:

1. Representing the Model: It is a system of abstractions which is used to describe selected aspects and is used to solve problems of domain. DDD is about creating highly expressive models which aim to create models that can be understood by everyone involved in the software department.
2. Bounded Context: A description of boundary within which a particular model is stated and applicable.
3. Context: It is a setting in which a statement is appeared which determines the meaning.
4. Strategic Design: It is about design in large and helps in focusing on many parts to make up a large model. In DDD these models reside in bounded context and their relation is known as context mapping.

5. Ubiquitous language: It is a language that is structured around the domain model and is used by team members for connecting all activities of the team with the software. It is a set of definition and terms which is used by the technical and non-technical team.
6. Modeling is domain design: Within the bounded context, efforts are focused on building expressive models which reveal the intention more than its implementation.
7. Application Architecture: The architecture in which the contribution of domain participants is done for keeping the model free of infrastructure. A layered architecture can be used for isolating domain from other parts of the system.

• User interface is used for constructing and managing the interaction with the domain model.
• Application is the layer which collaborates with the domain.
• Domain is a behavior-rich and expressive model and has factories and repositories which are a part of the domain.
• Infrastructure deals with specific technology decisions and the focus is more on implementation.

Building Blocks of Domain Driven Design:

1. Value object: It is an unchangeable object which has attributes but no distinct identity.
2. Entity: It is an object which is defined by a consistent thread of continuity.
3. Aggregate: It is basically a cluster of value objects and entities with boundaries defined around the group.
4. Service: It is a form of business logic or operation and cannot be related to a value object.
5. Domain Event: It is used to record a discrete event related to a model activity within the system. It is created for the type of events about which the experts of the domain care about.
6. Factories: Domain Driven Design uses a factory which encapsulates the idea of developing aggregates and complex objects ensuring that the client has no information about the inner-workings of object manipulation.
7. Repositories: It is a service which uses a global interface for providing access to all value objects and entities which are within a particular collection of aggregates. The goal of repository service for making data queries is to remove data query capabilities from the business logic of object models.

Pros of using Domain Driven Design:

1. Domain Driven Design uses patterns and principles for solving difficult problems in software and it helps in improving communication. When a common and ubiquitous language is established which is related to the domain model of the project, their teams will find communication to be easier throughout the development life cycle. Moreover Domain Driven Design will need less jargon when the aspects of application will be discussed as ubiquitous language will define simpler terms for more technical aspects.
2. It helps in writing a testable and clear code that represents the domain. Emphasis will be placed on Domain over Interface since Domain Driven Design will produce applications which are which are suited accurately and are representative of the domain at hand. The focus is on domain which means that Domain Driven Design approach will produce a product that works well with the audience associated with that domain.
3. It improves flexibility and better understanding as Domain Driven Design is based on the concept of object-oriented analysis and design and everything within the domain model can be based on an object and will, and can be quite encapsulated and modular.

Cons of using Domain Driven Design:

1. The use of Domain Driven Design is suitable for only when the domain is complex where business logic is complex and convoluted. However it is not suitable for applications which have marginal complexity of domain but have technical complexity.
2. The use of Domain Driven Design is time consuming and requires robust domain expertise. Sometimes, an integration of outside members of the team is required who can act as domain experts throughout the development life cycle.
3. The practices of Domain Driven Design are relied on constant iteration and integration continuously for building a malleable project which can adjust itself whenever necessary.