2

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!

Joshua0414
  • 21
  • 2
  • why write code to do the data import? why not something like BCP? Faster, simpler. – Mitch Wheat Aug 31 '21 at 01:17
  • There are actually around 30 external SQL servers with identical DB schema we pull from. There is logic going into which subset of servers (or all of them) is appropriate to import from at a given point of time. We felt options like BCP did not provide the needed flexibility or long-term extensibility. Moreover we would still need c# code to finish the hydration after data import. The hydration and inport need to happen at the same stage to prevent invalid data existing in our DB – Joshua0414 Aug 31 '21 at 02:19

1 Answers1

0

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.

ArwynFr
  • 1,383
  • 7
  • 13