DDD Repository vs Factory, Am I rehydrating or creating?

user_16168839 0
Viewed 182

We have an externally-owned SQL server with data that needs to be in our periodically ported into our team-owned (SQL) server.

The external and internal server share the same domain concepts but exist in very distinct forms. Transforming the object from its external form into our own domain form is a complicated process.

currently this is done like so:

  1. Adapter queries External Db, use Automapper to map to DTO (Adapter lives in infra layer)
  2. Adapter returns DTO to application layer (DTO defined in the app layer)
  3. Factory constructs domain object from DTO and factory loads related domain aggregates to set navigation IDs + other properties (Factory lives in app layer)

Is it proper to consider the work here by the factory as really building a new object since it's really hydrating an object from an external source, and we add further (required) decorations? The Entity ID stays the same as its transformed.

However calling this a repository also feels wrong as there is more work than just a simple hydration from a single DB?

I'm still new to DDD so any and all inputs are appreciated!

hexagonal-architecture ddd-repositories domain-driven-design c#
1 Answers

Your process is basically missing a layer and having an excessive mapping. What you should have is only 3 data models :

  • The source database model
  • The domain model
  • The destination database model

Your source and destination database models are entities (in the sense of EF, not DDD). They already are POCO/DTO, you don't need to map them to an intermediate model before converting them to domain model.

What your application should be doing is this :

  • Reading from the source database
  • Converting EF-entities to domain model
  • Validating some business rules
  • Converting domain model to destination EF-entities
  • Writing to the destination database

In order to do that, what I suggest you do is create an additional "contract" layer, in which you put assemblies for your EF models. You should have a single assembly for each database. I strongly suggest that these be generated using EF database-first tools. These assemblies will only contain EF models with db contexts used for databse read/write operations, and can be considered as an external service contract.

Your adapter layer will now basically act as a conversion layer between domain layer and contract layer. They will mainly consist of maps or factories, and repositories. In case of change in any database, you can simply regenerate the associated contract assembly and update any impacted adapter assembly (unless that change implies evolution in the domain model of course).

You entrypoint will be able to import your data by calling the source adapters repositories, which will query the source database and automap results to domain objects, then validate your business rules, and finally calling the destination adapters repositories, which will write into destination database after having automap domain objects to the destination EF-entities.

user_60928560
Related