Skip to main content
Detailled explanation about repository
Source Link

First of all, having your domain model being different from your persistence data is normal. If you take the traditional hexagonal schema, you can see that persistence is reached through an "adapter".

Then, picking in between your options. I believe the mapping in between both should be within a (persistence-oriented) repository, rather than a factory. In turn It sounds like a small naming difference, but it helps to make clear that a repository can do much more: for instance, when saving your DataCustomer, you may want to cascade save to several other data models.

Finally, that repository can call Automapper or use any other mechanism. What is really important in the end is that built aggregates have their invariants respected (all required fields are filled in...). From that point of point, I don't quite see the difference between the 2 approaches.

In a nutshell: you should be concerned about the quality of your domain model, not about the technical means to build it. The domain layer is more important than the infrastructure layer.

First of all, having your domain model being different from your persistence data is normal. If you take the traditional hexagonal schema, you can see that persistence is reached through an "adapter".

Then, picking in between your options. I believe the mapping in between both should be within a (persistence-oriented) repository, rather than a factory. In turn, that repository can call Automapper or use any other mechanism. What is really important in the end is that built aggregates have their invariants respected (all required fields are filled in...). From that point of point, I don't quite see the difference between the 2 approaches.

In a nutshell: you should be concerned about the quality of your domain model, not about the technical means to build it. The domain layer is more important than the infrastructure layer.

First of all, having your domain model being different from your persistence data is normal. If you take the traditional hexagonal schema, you can see that persistence is reached through an "adapter".

Then, picking in between your options. I believe the mapping in between both should be within a (persistence-oriented) repository, rather than a factory. It sounds like a small naming difference, but it helps to make clear that a repository can do much more: for instance, when saving your DataCustomer, you may want to cascade save to several other data models.

Finally, that repository can call Automapper or use any other mechanism. What is really important in the end is that built aggregates have their invariants respected (all required fields are filled in...). From that point of point, I don't quite see the difference between the 2 approaches.

In a nutshell: you should be concerned about the quality of your domain model, not about the technical means to build it. The domain layer is more important than the infrastructure layer.

Fixed typos
Source Link

First of all, having your domain model being different from your persistence data is normal. If you take the traditional hexagonal schema, you can see that persistence is reached through an "adapter".

Then, picking in between your options. I believe the mapping in between both should be within a (persistence-oriented) repository, rather than a factory. In turn, that repository can call Automapper or use any other mechanism. What is really important in the end is that built aggregates have their invariants respected (all required fields are filled in...). From that point of point, I don't quite see the difference between the 2 approaches.

In a nutshell: you should be concerned about the quality of your domain model, not about the technical meanmeans to build it. The domain layer is more important thatthan the infrastructure layer.

First of all, having your domain model being different from your persistence data is normal. If you take the traditional hexagonal schema, you can see that persistence is reached through an "adapter".

Then, picking in between your options. I believe the mapping in between both should be within a (persistence-oriented) repository, rather than a factory. In turn, that repository can call Automapper or use any other mechanism. What is really important in the end is that built aggregates have their invariants respected (all required fields are filled in...). From that point of point, I don't quite see the difference between the 2 approaches.

In a nutshell: you should be concerned about the quality of your domain model, not about the technical mean to build it. The domain layer is more important that the infrastructure layer.

First of all, having your domain model being different from your persistence data is normal. If you take the traditional hexagonal schema, you can see that persistence is reached through an "adapter".

Then, picking in between your options. I believe the mapping in between both should be within a (persistence-oriented) repository, rather than a factory. In turn, that repository can call Automapper or use any other mechanism. What is really important in the end is that built aggregates have their invariants respected (all required fields are filled in...). From that point of point, I don't quite see the difference between the 2 approaches.

In a nutshell: you should be concerned about the quality of your domain model, not about the technical means to build it. The domain layer is more important than the infrastructure layer.

Source Link

First of all, having your domain model being different from your persistence data is normal. If you take the traditional hexagonal schema, you can see that persistence is reached through an "adapter".

Then, picking in between your options. I believe the mapping in between both should be within a (persistence-oriented) repository, rather than a factory. In turn, that repository can call Automapper or use any other mechanism. What is really important in the end is that built aggregates have their invariants respected (all required fields are filled in...). From that point of point, I don't quite see the difference between the 2 approaches.

In a nutshell: you should be concerned about the quality of your domain model, not about the technical mean to build it. The domain layer is more important that the infrastructure layer.