I'm restructuring my current project to be better in-line with DDD best practices.
As part of this setup an admin-task allows certain domain-objects / aggregates to be (re)-bootstrapped based on a config file/algo combo. I have a good use-case for this that does require it to be part of a live system as opposed only to testing (text fixtures) for example.
I'm struggling how to best model refactor this in a DDD context:
Basically: would the builders/bootstrappers be infrastructure services belonging to the same Bounded Context as the Domain Objects? Would this feel natural? The flow I see is that an admin gets access to these functions using a special Admin Application Service which in turn calls the builders to do their work.
On the other hand, this admin functionality feels like a separate part of the system so perhaps I shouldn't pollute the domain objects (or their factories) with methods to support the bootstrapping. IOW: this could mean a seperate Bounded Context, with a completely different (logic-less) domain model purely used for persisting to a DB. That however doesn't feel very DRY to me, as I might end up defining models twice (once in each BC)
What would be the best way to go about this?