CODEWITHSUNDEEP
c#entity-frameworkdomain-driven-designn-tier-architecture
Mojo
Mojo

Reputation: 179

Separating persistence model and domain model

Finally starting to get the hang of Domain Driven Design, and in my mind it makes sense to separate the persistance model (PM) from the domain model (DM).

Since mapping from PM to DM should be done in the repository and the DM should be immutable and not know about the PM, should I just create a factory function that takes all the parameters but now call the event?

The service layer converts DTO to DM by using the factory functions, then maps back to DTO when task if finished.

Or go with the easy way and create a factory function inside the DM that takes PM as a parameter, and the other way around?

My solution would be: Trade some purity and clearness from DDD, to make the design a more efficient and decrease the complexity.

Upvotes: 1

Views: 889

Answers (1)

Subhash
Subhash

Reputation: 3260

The service layer knows about both all layers involved: DTO, DM, PM, and repository, so it is the best place to do all kinds of conversions.

In a typical flow, assuming you are acting on an API call, you would:

  • Construct a DTO from request parameters
  • Construct a Domain Model by transferring the DTO to a factory method in the Domain Model
  • Pass the new Domain Model to the repository for persistence (DM-to-PM and PM-to-DM methods are within the repository)
  • Convert the persisted Domain Model to a DTO to ship back to outer layers

Upvotes: 1

Related Questions