Knoldus Blog Audio
What is Domain?
To define domain-driven-design we should first establish what we mean by domain. The common dictionary definition of the domain is a sphere of knowledge, influence, or activity. In the context of software engineering, it refers to the subject area on which the application is intended to apply.
For example, if you are building an E-commerce software, in this case, sales will be the domain, and Seller, Buyer, Manager, Customer Executive, etc. will be the domain expert. But it might possible that those people are that expertized in software. So the purpose of DDD is to build a model that the domain experts understand.
Another common term used in software development is domain logic. The domain logic of an application refers to the higher-level rules for how business objects interact with one another to create and modify data.
What is Domain-Driven Design?
Domain-Driven Design is an approach to software design that glues the system’s implementation to a constantly evolving model, leaving aside irrelevant details like programming languages, infrastructure technologies, etc. DDD focuses on three core principles:
- It focuses on the core domain and domain logic.
- Base complex designs on models of the domain.
- Constantly collaborate with domain experts, in order to improve the application model.
A few more common terms that are useful when describing and discussing DDD practices are also defined in Eric Evans in his book.
1. Bounded Context
It is a description of a boundary within which a particular model is defined and applicable.
For example, outside of a Bounded Context, an “add” could mean two different things, either add a product to the cart or add a user. By defining a boundary context, you can determine its meaning.
2. Ubiquitous Language
It is a language, shared by the development team and the domain experts It is used by all team members to connect all the activities of the team with the software.
3. Building Blocks
Domain-driven design also defines a number of high-level concepts that can be used to create, express, and retrieve domain model within a Bounded Context:
Aggregates are collections of related Entities and Value Objects. Each Aggregate has an Entity that controls all access to the objects inside the boundary, this entity is the Aggregate Root. Rather than allowing every single entity or value object to perform all actions on its own, the collective aggregate of items is assigned a singular aggregate root item. As a result, external objects no longer have direct access to every individual entity or value object within the aggregate.
The Domain Model requires certain actions or operations that are not directly related to an Entity or a Value Object, in that case, such business logic can be implemented as a Service. Services are classes that offer stateless operations.
An object that has a unique identity and consistent thread of continuity. The Identity is maintained via a unique key or a combination of keys.
7. Value Object
An immutable object that describes characteristics, and that does not possess any unique identity is called Value Objects.
The repository is an interface that handles Read, Updates, and Delete operations. It hides the implementation details from the client. It operates as an abstraction layer over memory, file system, database, etc.
DDD suggests the use of a factory. Using Factories we can create complex objects and aggregates. So that the client has no knowledge of the working of object manipulation. Factories handle the Create operation.
Advantages of DDD
Domain-Driven Design gives software developers the principles and patterns to solve complex problems in software.
2. Business Logic
Domain-Driven Design creates business logic by explaining requirements from a domain perspective.
3. Better Code
With Domain-Driven Design you can write more readable code and less duplication.
Disadvantages of DDD
1. Time consumption
Software Developers have to spend lots of time with domain experts to understand the domain, as a result, it takes a lot of time.
DDD often took longer development and duration that ultimately translates to higher costs for the business.
3. Requires Domain Expertise
It requires strong domain expertise and regular communication between the domain expert and developers.
If you find this article interesting, please check out our other articles.