Domain Driven Design
Domain
Driven Design is all about understanding the customer real business
need.
We have heard of different domains such as Banking, Telecom, Supply
chain, health care, etc .So here domain means the business knowledge
about that
particular industry. Similarly domain driven design is something which
focuses
more into the business need not focusing on the technology.
We are about to start to write a system, here we first try to understand exactly what customer is looking for, what business they are going to do with the new set of applications in the system. During the initial phase you don’t even think about architecture or programming. Your prime goal is to understand all the terms of business that customer uses and how he/she models the requirement domain.
So what we follow is that the customer discuss each business case in business meetings. Domain driven design purely based on these assumptions to map the business requirement into domain model.
Domain Driven Design is all about how you model your Domain. It means each Domain class should have a direct relation to what it represents in the business domain. It is addressing either in the physical or real world. So a Customer object should be named a Customer in code - it should have the same rules as a Customer does in the real world or as close as it is possible.
Thinking of domain driven design over Normal Layered Architecture
Normal applications follow the following architecture. It works as expected but reaches many drawbacks when it comes to big enterprise systems.
The above architecture fails when the systems keep on growing for an enterprise application.
Typically a large enterprise application, when code base is more maintaining the code is difficult as one simple change in one place may affect in other place. So In this case we should think of domains. The following points are the key considerations for thinking for a domain model.
- You have a complex system to develop with many external, separate or legacy systems involved, large team size or multiple development teams.
- Your system has the same functionality implemented in the same way or different in different places. As developers are not aware about code of other sub systems or other applications in the codebase they change code at one place and it impacts at other place.
- You have more than one object for the same item.
- You have objects that have properties that are not actually attributes of that object.
- You have no or very poor relationship among related items.
- Looking at your objects it is not possible to understand what actually the whole application is all about.
- Where the business requirements change fast with high essential complexity (with a lot of correlated business rules).
- Fatty service layer code keep on going large day by day. No proper code organization and not easy to test the components.
- Business logic is isolated from non-domain and framework code.
- Adding or changing the service does not influence the domain or other services.
- Complexity is in the domain not the technology.
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
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.
