Entity Methods in DDD architecture

Asked

Viewed 514 times

3

Could you help me with a question. In DDD architecture what types of methods should I put in my Entity and which ones should I put in my Domain Service? I know that in my entity I must put at least the method of validation of the entity itself, and when to the rest of the methods I must put in the domain service or there are other types of methods I can put in the entity? Thank you.

  • An entity publishes all its behaviors. The services fit the behaviors that do not belong naturally to any entity.

1 answer

2


There are several approaches and choices that vary with specific domains, but in the DDD the idea is to make the entity as "rich" as possible.

This means that if you can put the method into a specific entity, and keep its attributes private, this is the best choice. That is, abuse of Object Orientation (encapsulation and cohesion).

A domain service should only be created when the business rule does not "fit" into a single entity, having to use Public Property from two or more entities.

  • Hello Fernando, thank you for the answer, but in the case of CRUD methods they should stay in the entity? For me it is a little confusing what by itself, what put in the domain service, what put in the application service or the application service is a copy of the domain service? For a newbie it gets a little confusing.

  • About Data Accuracy, the DDD advises the use of Repositorios, which are specialized classes for this, leaving their domain entities free of this responsibility. But again it becomes very subjective without a larger context. (what the project is about, whether to use the Entity Framework, etc)

  • 2

    The entity should not be as rich as possible, but only as rich as necessary, pursuing poverty far more than wealth; the same applies to any type of artifact in the system (we want to keep everything as simple as possible). In addition, a service does not perform the rule that "does not fit into one entity" but rather the rule that does not naturally belong to any entity. It’s not about sticking everything in the entity until you can’t take it anymore, it’s about finding the ideal person for each business rule.

  • This is more of a "play on words", I don’t see my response saying the opposite of what you said. But I think naturally we tend to create our systems in a very procedural way, and the more flexible we are in creating services, the more procedural the system will become.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.