DDD - CreatedBy/CreatedOn in the Domain Model?

Question

When writing an application by standard for each table in the database I have the following properties: CreatedOn, CreatedBy, ModifiedOn, ModifiedBy, Archived.

But trying to follow DDD I'm questioning whether these properties are truly part of the domain and should be included within the domain objects. If i were to exclude these "metadata" properties from the domain but still wanted them in my database then I'd need to implement some kind of DTO layer if I was going to use a ORM.

So the domain model is mapped to a DTO, the CreatedOn, ModifiedOn, etc is set and then pushed to the database.

So I suppose my questions are:

1. Do I just live with these properties as part of my domain model?
2. Do I remove them but have the headache of having to map DTO's?
3. Is there an alternative that would elimate both problems like implementing some form of audit log?

Answer 1

When doing Domain-Driven Design, your entities usually won't have much to do with the structure of the database.

You'll quickly come to a point, where you need to map between the ORM's table-objects and your domain's aggregates anyway.

Forcing database-driven aspects into your domain model contradicts what DDD is all about.

So yes, I'd recommend mapping the ORM's table-objects (which are pure data anyway) into your aggregates. This is where the Repository pattern comes into play. It will provide the domain's objects by transforming the underlying data.

If meta-data like creation/modification date and user are not inherently part of the business domain (i.e. a system-wide logging requirement) the given user and date/time can be injected when transforming back into table-objects to save.

An layered architecture might look like the following:

 ----------------------------
| Domain                     | (Aggregates)
 ----------------------------

 ----------------------------
| Repositories               | (transforms table-objects into Aggregates)
 ----------------------------

 ----------------------------
| OR-Mapper                  | (loads records from DB into table-objects)
 ----------------------------

 ----------------------------
| Database                   | (this is where the data lives)
 ----------------------------

Answer 2

The only way to find that out is by asking your product owner if those fields are relevant in your model. And if they are, which enteties are they relevant on?

---

If i were to exclude these "metadata" properties from the domain but still wanted them in my database then I'd [.....]

Why? They are not part of the model, which menans that they are not part of any logic in your domain.

3.Is there an alternative that would elimate both problems like implementing some form of audit log?

If an audit log is an requirement then they should be part of the model.