[Note]www.geeksforgeeks.org/domain-driv… Domain-driven Design is programmerEric EvansA concept developed in his 2004 book, Domain-Driven Design: Solving Complexity at the Heart of Software. This is a top-down approach to software design. First, let’s try to focus on what domain means in this context.

What is a domain?

In the context of software development, “domain” refers to business. During application development, the term domain logic or business logic is commonly used. Basically, business logic is the domain of knowledge around which the application logic revolves. The business logic of an application is a set of rules and guidelines that explain how business objects should interact with each other to process the modeled data. Note: The domain of the software engineering domain is the business on which applications are to be built.

Domain Driven Design:

The software design architecture is great, assuming our software uses all the latest technology stacks and infrastructure, but when we release the software to the market, it’s ultimately up to the end user to decide whether our system is good or not. In addition, if the system does not address the business needs, it is of no use to anyone; No matter how beautiful it looks, or how good its infrastructure is. According to Eric Evans, when we develop software, our focus should not be primarily on technology, but on the business. Remember:

“It’s not the customer’s job to know what they want” — Steve Jobs

Domain-driven design involves two kinds of design tools, one is strategic design tool, the other is tactical design tool. Programmers or developers typically deal with tactical design tools, but if we have knowledge and a good understanding of strategic design tools, it will help us build good software. Most frameworks under the Spring data family are built around a domain-driven design approach.

Strategic design:

Strategic design tools help us solve all the problems associated with software modeling. It is a design approach similar to object-oriented design, where we are forced to think in terms of objects. In strategic design, we are forced to think in terms of the environment.

Context:

We can think of this word as an English word that refers to circumstances of an event, event, statement or idea from which its meaning can be determined. In addition to context, strategic design discusses models, ubiquitous languages, and boundary contexts. These are common terms in strategic design for domain-driven design. Let’s take them one by one.

  • Model:

Act as core logic and describe selected aspects of the domain. It is used to solve problems related to the business.

  • General language:

A common language used by all team members to connect all team activities around the domain model. When talking to domain experts and team members, think of it as using generic verbs and nouns for classes, methods, services, and objects.

  • Boundary context:

Refers to the boundary conditions of the context. It is a description of the boundary and acts as a threshold in which it is defined and applied to a particular domain model.

Tactical design:

Tactical design discusses implementation details, the modeling domain. It typically deals with components in a bounded context. We’ve probably heard of or used things like services, entities, repositories, and factories. Both were created and popularized by domain-driven design. The tactical design process occurs during product development. Let’s discuss some important tactical design tools. These tools are high-level concepts that can be used to create and modify domain models.

  1. Entity:

Programmers working on object-oriented principles are likely to know the concepts of classes and objects. In this case, entities are classes with certain attributes. Instances of these classes have global identity and maintain the same identity throughout their life cycle. Keep in mind that property states may change, but identity never changes. In short, entities can implement some business logic and can be uniquely identified with ids. In a programming context, it is typically persisted in DB as a row and consists of value objects. 2.Value object:It is an immutable lightweight object with no identity. Value objects reduce complexity by performing complex computations, isolating heavy computational logic from entities.In the figure above,UserIt’s an entity,AddressIs a value object where the address can change many times, but the user’s id number never changes. Whenever an address changes, a new address is instantiated and assigned to the user. 3.Services:Services are stateless classes that can fit somewhere other than an entity or value object. In short, a service is a function that exists somewhere between an entity and a value object, but it is not related to either entity or value object. 4.Aggregation:When we have larger projects, object graphs get larger, and larger object graphs are harder to maintain. An aggregation is a collection of entities and values under the boundaries of a single transaction. It’s basically aggregation, controlling change, and there’s a root entity called an aggregation root. The root entity manages the life cycle of other entities in an aggregated manner.In the example above, if the root entityUser 或 OrderDeleted, the other entities associated with the root entity are useless, and the information for that association is deleted. This means that aggregation is always consistent in nature, with the help of domain events. Domain events are generated to ensure ultimate consistency. In the example above, if the user’s address has changed, it must also be reflected in the order. To do this, we can trigger a domain event from User to Order so that the Order updates the address, so that we have final consistency and the Order will finally be consistent. Other examples of aggregations and aggregations roots could be comments on posts, q&A details, banking transaction details, and so on. The ORM tools such ashibernateA lot of aggregation is used to create one-to-many or many-to-one relationships. 5.Factories and repositories:Factories and repositories are used to handle aggregation. The factory helps manage the beginning of the aggregation life cycle, while the repository helps manage the middle and end of the aggregation life cycle. The factory helps create the aggregation, and the repository helps persist the aggregation. We should always create a repository for each aggregation root, not for all entities. Factories are GoF’s design pattern, and factories are useful, but not mandatory, in the context of aggregation rules.

Advantages of domain-driven design:

  • It improves our skills
  • Provides flexibility
  • Prefer domains to interfaces
  • Communication gaps between teams are reduced through a common language

Disadvantages of domain-driven design:

  • A professional with strong domain expertise is needed
  • Encourage teams to follow iterative practices