Domain driven design, the basics

  

https://www.educative.io/courses/domain-driven-design/B8QQK86gyAQ

The Domain Driven Design (DDD) is a software architecture pattern that focuses on the domain of the application. It is a way to handle complex subjects, focused on business-related with the technical details.

One of the most important steps in this process is to gather information from the business experts. So, the idea of this post is to show you how to accomplish this task.

What is Domain?

There are several definitions of domain in the literature. The most popular one is the following:

“an area of knowledge or activity; especially one that somebody is responsible for”. Oxford Dictionary,

In this context, the domain is the area of knowledge or activity that somebody is responsible for.

A quick example of a domain can be:

For Banking Services: A Bank can have several services like Loans, Credit Cards, Account, Employees, ETM, etc. So, each activity is executed by an expert who handles that activity.

Each of that activities can be part of the core business process, whereas others can support the major activities.

For E-Commerce Services: A company of this kind can have several services like Sales, Stock, Shipment, Website, and Payments. So, each activity is executed by an expert who handles that activity.

Basically, the domain is the field or area in which the company operates. A domain can represent many different parts inside then.

What is SubDomain?

The subdomain is the multiple parts involved in the domain. The domain is not a whole, that is why it better break it into subdomains.

Types of subdomains:

  1. Core Domain: The core domain is the main domain that is responsible for the core business process. An easy example of a core domain for veterinary busiess can be appointments, medicine management, surgeries, and so on.
  2. Supporting Domain: The supporting domain is the domain that is responsible for the supporting business process, and contains all the acitivies that need to be built. An easy example of a supporting domain for veterinary business which needs to keep stock of the medicine to cure animals can be managing different types of medicine.
  3. Generic Subdomain: These activities are more related with common across many domains but not specific to any one domain.

It’s always necessary to work with a domain expert to understand the domain and subdomains.

So, in the end, What is the Domain Driven Design?

Domain Driven Design is a set of tools, principles, and patterns that help you to build complex applications.

In the book Domain Driven Design, of Eric Evans, he explains DDD as a strategy to convert complex problems into simple and manageable problems. The idea is to develop software based code on an envolving business model. This model is the representation of:

  • Structure
  • Activities
  • Processes
  • Actors
  • Interactions.

The DDD help us to:

  1. Support business processes in the design and development process. This is achieved modeling the domain and every subdomain, rather than defining the technological stack at the begining of the project.
  2. Break the domain into smaller pieces, called subdomains. Understand this subdomain to build the best model for the business model.
  3. Scrum oriented in order to generate the MVP concept creating a basic model that everybody understands. Evolving with each iteration.

DDD contains two approaches. The strategic approach is the one used in the real world by converting the model into the domain, here are some patterns such as bounded context and ubiquitous language. The tactical approach is the one that is used in the software development process translating from the model, here we have components like aggregate pattern or the repository pattern.

In summary, the DDD helps us develop complex applications business and represent this process in a model. When using DDD, you have very flexible software and are adaptable to the needs of the company, being able to change as needed.

The code is organized because the business logic lives in one place, and you can easily work with several architectures like the Hexagonal architecture.

Downsides of DDD

One of the biggest problems of starting with DDD is the learning curve, this is because DDD includes many principles, patterns and processes that might be difficult to understand. DDD is not the best approach for small or simple projects because can overcomplicate the development process.

Work in progress…

Mapping the Domain into the model

Event Storming

The events are the communications sent and consumed between different of subdomains.

So, convert the explanation of the Domain experts into technical experts can be difficult and somethimes it can be hard to understand each others. Most of the time the technical experts uses tools like UML witch domain experts might be difficult to understand. So, the idea is to create a** session where both sides share the same terms**, producing requirements similar for both sides, creating a domain model that is easy to understand. That idea is called Event Storming.

The Event Storming metting is a session or workshop work using stiky notes and toolks like that in order to create the domain model. The idea is create a detailed list of:

  • Events that are actions that happend in the domain.
  • Commands that are the intention of an actor.
  • Policies that are the prerequisites necesary to execute a command.
  • Actor that is the people or system that is going to execute the command.
  • Third party or external actors that are the actors that are not part of the domain.
  • Questions or concerns that are the questions pending to be resolved.
  • Read Model that is specific data that is used to make a desition or carry out an action. This task can be asociated with the commant or the event.
  • Aggregates that are the entities that are part of the domain and represent a specific business logic. Aggregate help us to find the bounded context.

All this rules, elements and considerations helps to understand all the elements involved in a subdomain process.

https://martinfowler.com/bliki/CQRS.html

Domain-Driven Design: Tackling Complexity in the Heart of Software | Eric Evans