object orientation – Business rules must stay in the Entity in the DDD approach


Following the DDD (Domain Driven Develop) methodology, my doubt is whether the entity class should receive any business rules.

Imagine the situation: We have a CarFactory responsible for building different types of cars, where instance specific classes of cars (entities)… Each entity must have within itself rules to receive specific values, such as color, port numbers, etc. …?

1-How should business rules be organized? Which layer is the business rule on? 2-Enitity must have value validators for their properties? Entity can receive an array with values ​​for the entity itself "set" values ​​for its properties or can there be a class that specifies values ​​that should be passed to the entity?



Entity are object classes and need to have an identity, that is, something that identifies that entity is unique. For example the id or uuid . In entities only attributes and accessor methods will go 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 that must be taken into account are the Factories and Aggregates , where each one has its responsibility so that only the business rules are placed in the service classes.


  1. DDD
  2. Area code E-book
  3. DDD Basic Project on Git
Scroll to Top