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.
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.
