DDD: как работать с одним объектом, хранящимся в нескольких системах хранения? - PullRequest
3 голосов
/ 12 июня 2011

В настоящее время я нахожусь в процессе миграции устаревшего приложения на модель проектирования на основе домена, и я столкнулся с такой проблемой: приложение предназначено для управления большим количеством контактов в режиме реального времени, включая проверку на наличие дубликатов.Каждый раз, когда кто-то сохраняет новый контакт, он должен пройти повторную проверку с помощью стороннего программного обеспечения (в основном это программное обеспечение для поиска сходства).Если он пройдет проверку, контакт будет создан в SQL, а небольшое подмножество контакта (некоторые основные поля, которые имеют отношение к проверке дубликатов) должно быть сохранено в базе данных стороннего программного обеспечения.Таким образом, сущность "контакт" живет в двух (синхронизированных) системах хранения, но одна система имеет только небольшое подмножество полей, тогда как в SQL есть более 50 полей для контакта.

Теперь я думал, все ли в порядкесоздать два типа для «контакта» (Contact и ContactShort).В результате мне также пришлось бы создать два репозитория для этих объектов и использовать эти репозитории в доменной службе, которая в конечном итоге используется для выполнения тех операций, где мне нужно программное обеспечение для проверки дубликатов (например, методы Сохранить / Вставить).

Есть ли хорошее практическое правило о том, как подходить к такому сценарию?

РЕДАКТИРОВАТЬ: Я до сих пор не нашел окончательного решения, но подумал немного об этом: Возможно, это было неправильнов этом случае отделить систему хранения дубликатов проверки от базы данных SQL.На самом деле, я думаю, что неправильно выставлять методы стороннего программного обеспечения.Это чистая инфраструктура.Поскольку операция сохранения никогда не должна выполняться без повторной проверки, я думаю, что вызовы стороннего программного обеспечения должны быть внутренними по отношению к SQLRepository.Он никогда не должен покидать уровень инфраструктуры, поскольку он никогда не сможет вернуть действительный объект контакта.Как вы думаете?

1 Ответ

1 голос
/ 12 июня 2011

Для меня предложенное вами решение звучит хорошо. На нижнем уровне (уровень доступа к данным) у вас должно быть два независимых объекта, которые обертывают доступ к двум различным базам данных (двум репозиториям, поскольку вам требуются разные строки подключения. Это может быть 2 экземпляра одного и того же XXXRepository, если вы используете один и тот же механизм базы данных, или это могут быть разные репозитории XXXRepository и YYYRepository для доступа к двум различным ядрам базы данных).

Однако на верхнем уровне (Domain Layer и GUI) вас не должно беспокоить, как и куда эти данные попадают. Как вы сказали, у вас есть сервис, который разделяет процесс, так что домен приложения и верхние уровни (например, GUI) не будут видеть, что происходит ниже (на уровне доступа к данным).

...