Business rules should be in the Entity in the DDD enclosure

Question

Following the DDD (Domain Driven Develop) methodology, my question is whether the Entity class should receive any business rule.

Just imagine the situation: We have a Carfactory responsible for building different types of cars, where instance specific class of cars (entities)... Each Entity must have within itself rules to receive special values, such as color, port numbers, etc... ?

1-How should the business rules be organized? Which layer q the business rule is? 2-Enitity must have value validators for their properties? Entity must receive an array of values for the Entity itself "set" values for its properties or there may be a class q espcifica values that must be passed to Entity?

Answer 1

Not,

As Entity are object classes and need to have an identity, that is, something that identifies that entity is unique. As for example the id or uuid. In entities will only access attributes and methods when needed.

When I develop using the DDD (Domain Driven Development) methodology, in my opinion, the service classes are responsible for the business rules.

But another point you should consider is Factories and Aggregates, where each has its own responsibility so that only the business rules are placed in the service classes.

References

1. DDD
2. DDD E-book
3. DDD Basic Project in Git

Answer 2

To answer your question it is necessary to divide it into parts:

Following the DDD (Domain Driven Develop) methodology, my question is whether the Entity class should receive some business rule.

Yes, when the business rule (in the DDD is called domain logic) "couber" within the entity (examples below).

Imagine the situation: We have a Carfactory responsible for building different types of cars, where instance class specifies of cars (entities)... Each Entity must have within itself rules for receive bonus values such as color, port numbers and etc.... ?

Yes. The color, number of doors, brand, engine, among others, are properties of the car, so the car entity is who should be responsible for carrying such properties.

However, it should be noted that depending on the domain, some of these properties may have a completely independent life cycle. As, for example, in a software for engine grinders, where the engine will have a more important role than the car itself. Soon, the Car entity will have a Motor property that, unlike color properties and number of doors, will be a new entity with its own life cycle.

1-How should business rules be organized? Which layer q the rule business is found?

Answered above. But to be clear: the basic rule is to think which class should have the responsibility to have and/or do something. In the example of the car, it is he who should know its color, number of doors and engine type. But it is not the car that should manufacture other cars, so the existence of a Factory.

2-Enitity must have value validators for their properties? Entity must be able to receive an array of values for Entity itself "set" values for its properties or there may be a class q values that must be passed to Entity?

Entities may and should receive values for their properties, but it is always necessary to think whether the validation and other behaviors of the property in question belong to the entity. Example: In the above case, the engine grinder, the Car entity may receive the Engine entity, but it is the Engine, and not the Car, who must validate if the number of cylinders of the Engine is correct.

Finally, if the domain logic does not fit in the entity, one can use one of the other building blocks of the DDD: Value Object, Aggregates, Events, Services, Repository and Factory. Learn more in https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks