DDD - CreatedBy / CreatedOn in a domain model?

Question

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

But trying to follow DDD, I wonder if these properties are really part of the domain and should be included in the domain objects. If I excluded these metadata properties from the domain, but still wanted them in my database, then I would need to implement some kind of DTO layer if I was going to use ORM.

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

So, I suppose my questions are:

• Am I just living with these properties as part of my domain model?
• I delete them, but have the headache of having to match the DTO?
• Is there an alternative that could justify both problems, such as implementing some form of audit trail?

Answer 1

When developing Domain-Driven Design, your objects will usually not have much to do with the database structure.

You will quickly go to the point where you still need to map between the objects in the ORM table and the aggregates of your domain.

Forcing database-based aspects into your domain model is contrary to DDD.

So yes, I would recommend matching ORM object tables (which are pure data anyway) in your aggregates. The repository template is played here. It will provide domain objects, transforming the underlying data.

If metadata, such as the creation / modification date and the user, are not an integral part of the business domain (i.e. registration requirements within the entire system), this user and date / time can be entered when converting back to table objects for saving .

A layered architecture might look like this:

  ---------------------------- | 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 out is to ask your product owner that these fields are relevant in your model. And if they are, what measures do they matter?

---

If I excluded these metadata properties from the domain, but still wanted them in my database, I would [.....]

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

3. Is there an alternative that could solve both problems, such as implementing some form of audit trail?

If the audit trail is a requirement, it should be part of the model.

Answer 3

I agree with the other answers that say that "metadata" is not necessarily part of the domain.

If your domain is an identity and access management area, you will have usernames and the like. For something that uses Identity and Access BC may be different. You may need to add some user information to your domain as a value object.

For the most part, I believe that this data is related to the application service level. This may be the option of having some context object populated by the application service to which your repository has access to fill in the corresponding database fields. Thus, it remains outside your model.