DDD Architecture
To start this article, let’s use this quote from Eric Evans: “The heart of software is its ability to solve domain-related problems for its user.” Who is Eric Evans? The most important propagator of Domain-Driven Design, and creator of a book with the same name, written in 2003. Now, let’s decipher this quote…
1. What is Domain-Driven Design?
Fundamentally, DDD follows development to protect the principles of focusing application design in line with business domains.
The domain is where we solve all business and related issues and build application dependencies through them. This prevents the system from finding dependencies on frameworks or external code that don’t make sense.
All developers should have good knowledge in this field. How can I get this knowledge? So, the separation of skills from true domain knowledge makes sense for applications with large teams.
As business rules become more complex, DDD becomes more important.
2. Ubiquitous Language
Ubiquitous Language is a core concept of DDD, let me show you an image before I explain:
The image shows that there are two languages: business and technology or development. Any solutions working with these languages? A common language, in this case a Ubiquitous language.
In this way, a clear exchange of information between technicians and entrepreneurs is ensured, resulting in domain code that everyone can understand.
The Ubiquitous Language helps us know what kind of database model we want to create, how to name our objects, interfaces, methods, and finally how our code works.
3. DDD Layers
1- Domain layer:
This part reflects the entire business logic of the application and elements here should be as abstract as possible. It has basic interfaces, entities, and everything that’s really important to your business.
All team members must understand the domain. It’s important to know that this level shouldn’t depend on any programming language and you’re not working with databases in your domain.
2- Application layer:
Applications create and use domain objects by calling methods and implementing interfaces obtained from the business. This is where business process flows are handled. Here you can call the repository, store information and do many other things.
3- Infrastructure:
This layer calls external frameworks such as ORMs, databases, messaging services, and email services.
Domain and application are implemented here, so our business does not depend on external libraries and can easily change the external components used here, but always follow the domain and application logic.
4- UI (User Interface):
This layer is where interaction with external systems takes place. This level is the gateway to the impact of people, applications, or messages on the domain. Requests are accepted at this layer and responses are generated at this layer and presented to the user.
4. Benefits of DDD
The benefits of using DDD is that it helps ensure that the software system you create matches your organization’s business goals and requirements. This is achieved by working with domain experts to create a deep understanding of the domain and using this understanding to inform the development and implementation of software systems.
Do you like DDD?
See you later, Bye!
