Introduction To Domain Driven Design

Concepts of Domain Driven Design

Context

Contexts are portions of the solutions space. The setting in which a word or statement appears that determines its meaning.

Domain

The subject area to which the user applies a program is the domain of the software. It is also termed as sphere of knowledge. In a banking system the following are the highlighted domain models.



Model

A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. The Domain Model itself could be a diagram, code examples or even written documentation of the problem. The important thing is, the Domain Model should be accessible and understandable by everyone who is involved with the system.

Domain Expert

Domain expert is a person who is an owner in a particular area or topic.

Consider a banking system there can be different domains such as Retail Banking, Corporate Banking, Home Lending, Investment Banking, Insurance, cards services, ATMS are of different type of domains. One dedicated person with expertise to a specific domain will be responsible to handle end to end business deliverables and solutions what a business need. Domain experts works closely with developers, end user, project management to successfully deliver a system.

Ubiquitous Language

Ubiquitous language is a language communicated around the domain model and used by all team members to connect all the activities of the team with the software.



Bounded context

A Bounded Context is the boundary in which domain model particular works. This keeps isolated from other domains.

Multiple domain models are in play on any large application. When code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. So it is recommended to keep the domain model thin.

Context map

A Context Map is the integration of all the domain models in the systems. Each model might have been developed independent of each other. Over the time the proper integration needs to be done in order to make the system to work from end to end.

For example, an online-retail store company might have one system putting in orders, one for inventory, one for shipping (including tracking), one for payments, etc. Here combination of everything makes the stores business efficient and complete.

Architecture of DDD and Element of DDD

When going for Domain driven design, these are the element of domain driven design.



Entity: An object that can be identified uniquely or by its identifier. Entity can be identified either by its ids or combination of some attributes. Entity is an identity.

Bank Accounts, Loan Account number, Borrower Info, Underwriting Decision, Funding Request are few example of an entity in a banking application.

Value Object: An object that contains attributes but has no conceptual identity.

They are descriptors or properties which are important in the domain you are modelling. Value objects mainly have no setters and immutable in nature. They don't have an identity but they describe the things that do have identities.

Person: is an entity.

Address: is a value object; because 2 people can have same address.

Aggregate : A collection of objects that are bound together by a root entity, otherwise known as an aggregate root. The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members. The idea of an aggregate is to guarantee consistency, being the root responsible for data integrity and forcing invariants.

Example: When you drive a car, you do not have to worry about what the attribute make it move, making the engine combust with spark and fuel, etc.; you are simply driving the car. In this context, the car is an aggregate of several other objects and serves as the aggregate root to all the other systems.

Domain Event: A domain object that defines an event (something that happens) and is an event that domain experts care about.

Service: Services can be categorized into three types in domain driven design.

Services can be of three types:

• Domain Services
• Application Services
• Infrastructure Services

Domain Services: Domain Services contain operations, actions, or business process and provides the functionality that the domain needs. It deals with all the domain related manipulation.

An example of domain services are catalog service for ecommerce domain which deals with all the catalog related information or account service in accounts domain which deals with all information related to accounts.

Application Services: Application Services are the services used by the outside world which may have representations of data. Example of application service is a database CRUD operation.

Infrastructure services: An Infrastructure Service is service that communicates directly with external resource . For example, accessing file system, registry, SMTP, database etc in the application.

This is some of the basic understanding of Domain driven design. I hope you now have an understanding of Domain Driven Design. Thanks for reading.