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:
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)
----------------------------