Search code examples
domain-driven-designddd-repositories

in DDD how do you handle entity fields like updatedAt?


In DDD how do you handle entity fields like updatedAt ? Who is responsible for updating this fields when the entity is modified ? is it domain layer responsibility ? or infrastructure layer (database trigger on UPDATE) ? or in the application layer, calling $entity->setupdatedat() just before $entity->persist() ? If it's domain responsibility do we have to use some kind of event listener/subscriber pattern in the domain ? something else ?

What is the DDD best practices ?

Thanks


Solution

  • If it is a domain concern (our business policies care about clock readings), then the domain logic will normally get a clock/timestamp as one of its inputs, and we can then store a representation of the time in the data model so that it is available the next time we load the aggregate.

    If it is a plumbing concern, then we let the plumbing handle it. That might mean that the application copies metadata into the data model, or it could mean that our data model storage (ie: the database) does it automatically.

    Sometimes, you can figure out which is which by noticing where the requirement is coming from? If this is something that the domain experts want, it is more likely to be a domain concern; if the requirement is coming from some cross-cutting concern (IT, security), then it is more likely to be "just" metadata.