Learn DDD Summary

Entity

Entities are business objects that are analyzed in a business system, such as users, products, and so on, which need to persist over the data layer and have their own properties.

But the entity is not the data carrier required by the data presentation layer, it is just a business carrier. It defines the business methods for this entity and persists the changes to this entity to the data tier by these business methods.

An entity does not provide a way to directly modify its internal business properties, that is, there is no setter method. Changing the internal business attribute can only be handled by means that can express the business and can express the common language.

An entity does not provide a way to directly read its internal business properties by publishing its business properties (or restricting access) through value objects.

Value Object

is a immutable object that hosts data.

It is generally understood that it is used only to transfer data, and it is independent of the specific business model. In general, it is the data representation of the entity, because the entity is only a business carrier, there is no ability to display data, so the entity wants to display the data to the display layer, it is necessary to convert to a value object, so that the display layer renders the value of the object can be, again, this also solves how not to use osiv problem.

Domain Services

There are some business operations that are most likely to be Domain Services when the bad boils down to a solid method.

Or if there is a big process, a lot of business rules, and the bad thing boils down to the entity method, then it must be the domain service.

Domain Services have the following characteristics:

1. Call multiple entities to collaborate on a complex logical business process.
2. The entity converts the value object.
3. The return value is a value object.

Too much emphasis on domain Services can lead to anemic models, so when is the use of entity methods and when is the domain service?

1. Because entity business attributes are not directly accessible to the outside world, when you want to access these business attributes to complete the business functions, you need to implement the entity approach rather than the domain service.
2. When a business operation is done by a number of different entities, and the business flow is quite complex, let's say, if it has to be implemented by an entity method, but the caller needs to invoke multiple entity methods to complete the business operation, then this business operation needs to implement a business approach to the domain service.
3. If the above two points are mixed, then it is necessary to achieve a domain service, but the working scope of the entity method will be narrowed.

Domain Events

The classic observer pattern, but it's quite useful here. Mainly reflected in the following aspects:

1. More focused on the business itself, and the additional business generated by the business itself can be realized as a more focused business unit.
2. Business and ancillary operations are decoupled, and the system is easier to scale.
3. Easier integration with other sub-systems.

Domain events provide the possibility to refine the business by developing large, complex systems.

Learn DDD Summary