The Ubiquitous Language ought to be completely practices all through the modelling process keeping in mind the end goal to encourage communication between the software specialists and the domain experts, and to find key domain ideas which ought to be utilized as a part of the model. The motivation behind this modelling procedure is to make a good model. The next part is to implement the model in code.

The model need to be built with an eye open to the Software and Design plan. Designers should be incorporated into the modelling procedure as well. The primary thought is to choose a model which can be suitably communicated or implemented in the development stage. So that the outline procedure is direct and in light of the model. Firmly relating the code to an underlying model gives the code significance and makes the model relevant.

Getting the designers participate in the discussion gives feedback. It makes beyond any doubt that the model can be executed in software form. If something isn't right, it is detected at an early stage, and the issue can be effectively remedied. Anybody in charge of changing code must figure out how to reflect the change to the model through the code.

Key Elements of a Model-Driven Design:

When we make a product application, a substantial piece of the application is not straightforwardly related with the domain, but rather it is a piece of the infrastructure or serves the application itself. Object Oriented Program consists of UI, database, and other support code which gets frequently written specifically into the business objects. Business logic is implanted in the conduct of UI widgets.

In any case, when domain related code is blended with the other layers, it turns out to be to a great degree hard to see and consider. Subsequently, segment an complex program into LAYERS. Create an outline inside each LAYER that is strong and that depends just on the layers beneath.

A typical architectural solution for Domain- Driven outlines contain four theoretical layers:

1. UI
2. Application
3. Domain
4. Infrastructure

It is vital to partition an application in discrete layers, and set up principles of connections between the layers. On the off chance that the code is not unmistakably isolated into layers, it will soon turn out to be so caught that it turns out to be exceptionally hard to oversee changes. Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code.

Entities:

Consider a bank account system. Each record has its own number. A record can be correctly recognized by its number. This number stays unaltered for the duration of the life of the framework, and guarantees progression. There are diverse approaches to create a unique identity for each object. The ID could be consequently produced by a module, also, utilized inside in the software without making it visible to the client. It can be an primary key in a database table, which is guaranteed to be one of a kind in the database.

There are also performance implications in making all objects entities.

Value Objects:

There are situations when we have to contain a few traits of a domain element. We are not intrigued by what object it is, but rather what attributes it has. An object that is utilized to depict certain parts of the domain, and which does not have an identity, is named Value Object. Value objects are immutable. They are created with a constructor, and never modified during their life time.

Services:

Services is a state of association between many items. Such an object does not have an inside state, and its motive is to just give usefulness to the domain. Services can be available in Domain layer, infrastructure or application layer.

Modules:

Organizing related concepts and tasks in a container in order to reduce complexity is called a Module. The Model tends to grow bigger and bigger and understanding interaction between different parts becomes difficult hence Modules are needed.

Software code should have a high level of cohesion and a low level of coupling. Cohesion starts at class and method level, can be applied to modules as well. It is advised to group highly related classes into modules to provide maximum cohesion.

Types of Cohesion

• Communicational cohesion: When parts of the Module operates on the same data it is called Communicational Cohesion.
• Functional cohesion: When all parts of the module work together to perform a well-defined task it is referred to Functional Cohesion.

Modules should have well defined interface accessible by other modules.It is better to access one interface than calling different objects of the modules. Give the modules names that becomes parts of Ubiquitous. Modules remains unchanged, while its internals can change.

Domain Objects:

These are objects which are created, their state changes, placed in memory, used in computations and finally destroyed. In some cases these objects are stored in database as well.

If life cycle of Domain Objects are not handled properly it can lead to negative impact on Domain Model.

Patterns to deal with it:

• Aggregates Factories and Repositories
• Aggregate is a domain pattern used to define object ownership and boundaries.
• Factories and Repositories are two design patterns which help us deal with object creation and storage.

Aggregates:

An Aggregate is a gathering of related items which are considered as one unit with respect to data changes. Each aggregate has one root. Just root is accessible from outside. Changes can be made to root only by an outside object. An outside object can hold reference to root object. But the internal objects can hold reference to different root objects as well.

Factories:

Entities and Aggregates can frequently be huge and complex. Making complex Aggregates are in conjunction with domain where things are made by other things. It is like having Printer Fabricates itself.

This implies every client of the object will hold particular knowledge about the object built. This breaks encapsulation of the Domain objects and of the Aggregates.

Object Creation

Move the responsibility regarding creating instances of complex objects and Aggregates to a different object. Creation of a object can be a noteworthy operation. Factories are used to encapsulate the information essential for object creation, and they are particularly helpful to make Aggregates. At the point when the root object is created, it is important that all the objects subject to invariants are created as well.

Constructor can replace factories in some instances. Construction is simple, no sub objects have to be created, no hierarchy involved.

Repositories:

When a client wants to use an object, it accesses the database, retrieves the object from it and uses it. Objects can be obtained directly from the database. It solves the problem of giving reference objects.

Other solution is that the client fires queries to access objects of database. This breaks the encapsulation of the aggregates.

As a solution, we use a Repository, the purpose of which is to encapsulate all the logic needed to obtain object references. The domain objects won’t have to deal with the infrastructure to get the needed references to other objects of the domain. just get them from the Repository.A created objected may be stored and retrieved from the repository itself. If not present in Repository go to storage then. Repository acts as a storage place for globally accessible objects. Overall effect is that the domain model is decoupled from the need of storing objects or their references, and accessing the underlying persistence infrastructure.

A Repository should have a set of methods used to retrieve objects. client calls such a method and passes one or more parameters.

Relationship between Factory and Repository:

While the Factory is concerned with the creation of objects, the Repository takes care of already existing objects(Persistent Storage). Objects are either created using a constructor or they are passed to a Factory to be constructed. When a new object is to be added to the Repository, it should be created first using the Factory.

Important Chapters in Domain Driven Design

• Domain Driven Design Chapter 1
• Domain Driven Design Chapter 2
• Domain Driven Design Chapter 3
• Domain Driven Design Chapter 4
• Domain Driven Design Chapter 5