search

PacktPublishing / Hands-On-Domain-Driven-Design-with-.NET-Core

Hands-On Domain-Driven Design with .NET Core, published by Packt
MIT License
636 stars 206 forks source link

Separating the Domain Models from Data Models #5

Closed Milad101 closed 4 years ago

Milad101 commented 4 years ago

Is it okay to separate the domain models and data models and instead use translators/mapper to convert one to another? Although when we create the domain models we use the methods of the domain models e.g SetTitle so we ensure that the domain model is in good shape. but what happens when EF retrieves the data from db and through reflection sets the property values while someone made a mistake and changed the data directly on the DB? That bad data for instance in a finance application can cause lots of miscalculations till someone realizes it.

alexeyzimarev commented 4 years ago

Absolutely. The persistence model has little to nothing to do with the domain model. I used the approach which was simplest to implement, with documents and an ORM framework, but those are just options. As you find in event sourcing chapters, there the persistence has no translations.

gaurav-packt commented 4 years ago

Thanks for the feedback; with this I'm closing the issue.