Краткое описание проблемы - предоставление фабрик, которые по-разному создают один и тот же тип объекта, и соблюдение правил DDD (модель изолированного домена, внутри нее независимые объекты домена).
У меня есть некоторые доменные объекты в моей программе и пара функционально различных блоков , которые удовлетворяют некоторым потребностям моей доменной модели и ее объектов. Теперь я столкнулся со следующей проблемой - некоторые из функциональных блоков вне моей доменной модели должны создавать доменные объекты (например, адаптер базы данных - когда я загружаю объект обратно, мне нужно его воссоздать) - но это также означает, что ядро моей доменной модели больше не такое изолированное , как я хотел бы (а также, насколько я понял, согласно DDD концепции домен изолирован и не должен подвергаться изменениям в других функциональных блоках);
Автор DDD предлагает использовать фабрики для создания объектов - и концептуально это может решить мою проблему - и, например, это явно упоминается в книге (Часть 2, Глава 6, стр. 145 «Восстановление хранимых объектов»), что для реконструкции объектов вам нужно иметь отдельную фабрику - потому что объекты будут создаваться по-разному.
Другая сторона этой проблемы я сейчас сталкиваюсь это юнит-тесты - у меня могут быть юнит-тесты в другом функциональном блоке, который использует do основные объекты для тестирования поведения, но это также означает, что внутри тестов мне нужно создать объекты для фактического выполнения теста - и опять же, мне нужно установить только ограниченное количество полей, и мне все равно - но если я делаю это явно в тесте, тогда, когда я буду модифицировать свою модель домена, мне нужно будет обновить уже 2 отдельных функциональных блока, от которых мой домен модели обычно должен быть независимым - уровень БД и модульные тесты в каком-то другом уровне.
Я думаю, что это можно решить, предоставив фабрики для разных способов создания одного и того же экземпляра типа объекта - но я пропускаю примеры и я не могу понять, как могла бы выглядеть реализация например, из-за ограничений шаблонов Factory - вам нужно иметь одну интерфейсную функцию (например, create () или create (argsList)) - но это именно моя проблема - я хочу сохранить объект только с одним ctor и после некоторых модификаций этот объект домена я хочу избежать обновления других функциональных блоков - я Я бы предпочел обновить 1 фабрику, ответственную за эту конкретную часть функциональности объекта.
Я был бы очень благодарен за любые примеры такого конкретного случая использования или совета, заранее спасибо! PS Я нашел какой-то пример в TypeScript (http://www.taimila.com/blog/ddd-and-testing-strategy/), но кажется, что это невозможно в C ++ с нашим механизмом аргументов по умолчанию
Вот схема решения, которое я пытался создать: 
Как, согласно DDD концепциям, можно реализовать такую фабрику? API для меня не понятен. Я могу себе представить, что если, например, domainFactory имеет некоторые уникальные атрибуты (например, поле CustomType), мы можем внедрить эту дополнительную переменную в ctor фабрики - но только в случае, если эта переменная является общей для экземпляров - она не будет работать, если переменная уникальна для экземпляр объекта.
Я также могу представить себе случай, когда все другие фабрики используют DomainFactory, но что если другая указанная фабрика c (например, StorageFactory) попытается передать то, чего не ожидает Домен (например, загружен) уникальный идентификатор) - и как они могут общаться, используя только один метод API «создать»?