Introduction: What is Domain-driven Design?
Domain-driven design (DDD) focuses more on the business needs compared to technology. It’s all about understanding the customer’s real business needs. Domain-driven design consists of a set of patterns for building enterprise applications from the domain model out. During software development, a DDD approach is used to solve complex implementations problems. DDD puts the emphasis squarely on the domain model; the main focus is creating a conceptual model that forms a common language for both the users and programmers.
Advantages of Domain-driven Design
Your code will be very flexible, easier to understand, and quickly changeable and extendable by following DDD. Following are the advantages of using Domain Driven Design:
- DDD provides the principles and patterns to solve difficult problems of software applications as well as business problems. These patterns have been successfully used to solve complex problems.
- DDD is already proven; it has a history of success with complex project implementations. It aligns very well with the experience of developers and successful software applications already built.
- It helps us write clear and testable code that represents the domain.
- DDD helps us better understand client requirements. By following Domain-driven Design, the output code is generally much more close to the customer’s vision and perspective of problem solving. The resultant code is also easier to write and read. It is much better organized and it should have fewer issues and should be easier to test.
Concepts and Elements of Domain-driven Design
Context
Bounded Contexts are portions of the solutions and placed is a central pattern in Domain-driven Design. It is the strategic design section dealing with large models and teams. Several DDD patterns explore alternative relationships between contexts.
Context Map
A Context Map is the global view of the application. Each Bounded Context fits within the Context Map to show how they should communicate with each other and how data should be shared. 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 time, proper integration needs to be done to make the system to work from end to end.
Domain Service
Domain Services contain operations, actions, or business process and provide the functionality that the domain needs. It deals with all the domain-related manipulation.
Application Services
Application Services are the services used by the outside world which may have representations of data. A example of an 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, and so forth in the application.
Model
The Model usually represents an aspect of reality or something of interest. It’s an abstraction that describes the selected aspects of a domain. It’s often used to solve problems that are related to that particular domain.
The Model is also a simplification of the bigger picture and important aspects of the solution are concentrated on it. This means your Model should be focused knowledge around a specific problem that is simplified and structured to provide a solution.
Domain Expert
A Domain Expert is a person who is an authority in a particular area and an owner of a topic. By using DDD, we build around the concepts of the domain and around that domain experts will be advising. A Domain Expert will be able to understanding the requirement.
Entities
An Entity is an object that can be identified uniquely or by its identifier. An Entity can be identified either by its IDs or a combination of some attributes. An entity is an identity.
Value Objects
A Value Object is an object that contains attributes but has no conceptual identity. It is a descriptor or property which is important in the domain you are modeling.
Ubiquitous Language
Ubiquitous Language is the practice for building up a communication language between developers and users. It helps developers and the business share a common language platform that both parties understand to mean the same things. Ubiquitous Language should evolve as the team’s understanding of the domain grows.
Repository
A Repository mediates between the domain and data mapping using a collection-like interface for accessing domain objects. It is more like a façade to your data store that pretends to be a collection of your domain. A Repository provides a centralized façade, storing data in a database, XML, SOAP, REST, and so on.
Persistence Ignorance
The principle of Persistence Ignorance (PI) is a property of your domain model or business model. The model is persistence ignorant because it retrieves instances of the entities it contains through abstractions.
Aggregates
Aggregates are a collection of objects to calm the complexity by reducing the connected objects into a single unit that are bound together by a root entity. It’s a cluster of associated objects that we treat as a single unit.
Conclusion
I hope that, after reading this article, you have got the basic concepts and terminologies of Domain-driven Design. DDD turns around the concepts of object-oriented design; developing applications with DDD is a big challenge. Happy reading!
