Domain-oriented or domain-based design has as its main objective that the software we are developing or implementing reflects the real-world system we are trying to develop. Within the DDD we could define a domain as that unit of knowledge around which the business logic or business logic that we want to implement is centred or revolves.
We could say that the Domain is the basic unit around which all our .net developmentwill revolve, it will be the heart of our application. The primary goal of DDD is to manage software complexity by aligning the software model with the real-world domain it is intended to serve. With a focus on the core domain and domain logic, DDD enables product teams to create more expressive, maintainable, and scalable software solutions that better meet business needs.
Objectives of applying DDD and what it is
We could say, although it is very obvious, that the main objective of applying DDD or Domain Driven Design in English is to be able to isolate the code that belongs to the domain from the technical implementation details. In this way, we can treat it independently and thus focus on the complexity of each one.
If we focus on domain-oriented development, we must take into account that a team that is aware and prepared for this type of development will be needed. On the one hand, we will need the domain experts and on the other hand, the developers who will be part of the technical side.
In a traditional system we would have an analyst who would speak with the business team and the needs would be transferred to the development team, with the latter dedicating themselves solely to the programming part. This traditional approach is used to lead to some problems, such as omission of some information, lack of understanding or developers having to decide on an implementation due to a lack of knowledge of the business.
It is for the previous reason that this system seeks greater interaction between the programmers and the business team. In this way, a greater understanding will be achieved and both will be able to be involved in a much more active way.
All of the above entails a learning curve and a greater increase in project costs, at least in the beginning. But in the long run, it will result in a reduction in costs and in much more reliable software with a greater capacity to be able to carry out tests on the domains that are created. It must be taken into account that this type of orientation is usually applied to somewhat complex and large developments where new functionalities may appear, or for legacy systems to be able to migrate them to other technologies. Therefore, the creation of new pieces that can interact with each other in constant evolution is facilitated.
Core Principles of Domain-Driven Design
We could say that domain orientation focuses on three basic pillars:
● Focus on the core domain and business logic.
● Convert complex designs into domain models.
● Constant interaction and collaboration with domain experts will help resolve doubts and interact more with the development team.
Common terms in DDD
In DDD there are a series of common terms that I define below:
● Context: It is the setting in which a word appears, and this setting defines its meaning. These sentences or words are only understandable in their context. The setting in which a word or statement appears determines its meaning. Statements about a model can only be understood in a context.
● Model: A model is an abstraction of a system that describes aspects of a domain.
● Universal Language: It is a language structured and defined for a domain model and used and understood by all members.
● Bounded Context: A Bounded Context defines the description of a boundary within which a particular model is defined and applied. Typically, this is a specific piece of equipment or a subsystem.
Domain Drive Design Structure
When we work with DDD there are three parts that we must take into account:
● Separation of responsibilities into layers, isolate the domain
● Model and define the model.
● Manage the life cycle of Domain objects.
Separation of responsibilities into layers: Isolate the domain
As we have discussed previously, DDD focuses on separating the model from the development. To do this, the domain must be isolated and separated into layers that are readable and understandable.
We could do this division following the following layered structure:
● Presentation.
● Application.
● Domain.
● Infrastructure.
Layer model in DDD
An architecture that could perfectly fit with that solution and fits very well with DDD is the hexagonal or ports and adapters architecture.
- Presentation layer
Shows the information to the user.
- Application
This layer defines the use cases that are transferred to the software. It will try to keep it as simple as possible and will delegate the tasks of the domain objects to the next layer.
- Domain
The domain layer will be responsible for representing business concepts, as well as particular rules and situations. It must be taken into account that this layer is the main one of the business.
- Infrastructure
This layer allows interaction between the 4 layers through some framework. This is where the technical part of the application resides.
Understand the domain model level(DDD)
Domain Model Level: Responsible for representing business concepts, business situation information, and business rules. The state that reflects the business situation is controlled and used here, although the technical details of its storage are delegated to the infrastructure. This level is the core of enterprise software.
The domain model level is where the business is expressed. By deploying a microservice domain model tier in. NET, this level is coded as a class library with domain entities that capture data and behaviour (methods with logic). Following the principles of persistence bypass and infrastructure bypass, this level should completely bypass data persistence details. Persistence tasks must be performed by the infrastructure layer. Therefore, this level should have no direct dependencies on the infrastructure, which means that an important rule is that the domain model entity classes should be POCO.
As we have seen in this introduction to Domain Driven Design – DDD, this model will help us in building our software architectures, although with a learning curve that can sometimes be tough, the reward is worth it. Domain-driven design could be used for many more articles and could go into much more depth, which is why we recommend IntellisourceImplementing Domain-Driven Design or tackling complexity in the Heart of Software.