DDD и MongoDB: можно ли разрешить Mongo создавать ObjectID?

Согласно DDD (Синяя книга, Эванс) фабрика несет ответственность за создание сводного корня в допустимом состоянии. Означает ли это, что он должен иметь возможность создавать технический идентификатор (objectId в мире mongoDB), а также идентификатор домена?

С одной стороны, это кажется технической деталью, и было бы нормально позволить Mongo заняться созданием идентификатора.

С другой стороны, включение запросов по идентификатору (при наличии getById в репозитории DDD) предоставляет домену технический идентификатор, что, в свою очередь, возлагает ответственность на Фабрику за его создание.

Возможно, я не могу понять различные варианты использования/перекрытия и т. д. технических идентификаторов и доменных идентификаторов, или, возможно, я переусердствую, но в любом случае я был бы признателен за ваше мнение.

Вкратце: В DDD: Должна ли фабрика иметь возможность создавать технический идентификатор, а также идентификатор домена?

возможная реализация: Hi/Lo ( Как установить начальное значение последовательности hilo в MongoDB Norm?)

РЕДАКТИРОВАТЬ: хотя способ hi/lo подвергает Фабрику уровню сохраняемости, о чем должен знать только Репозиторий. Хм

Спасибо


mongodb factory-pattern domain-driven-design hilo object-identity
person Geert-Jan    schedule 02.08.2012    source источник
comment
Мелкий не совсем актуальный комментарий; MongoDB на самом деле не создает идентификаторы, это делает клиент (драйвер) (за исключением операций upsert).   -  person Remon van Vliet    schedule 03.08.2012

Ответы (1)


arrow_upward
3
arrow_downward

Фабрики не должны заботиться об идентификаторе, потому что достоверность агрегата ортогональна идентичности. Идентификатор может быть назначен несколькими различными способами: либо как инкрементный идентификатор из реляционной базы данных, и в этом случае репозиторий должен управлять им, либо как UUID/GUID, и в этом случае он может быть назначен фабрикой или репозиторием или даже вызывающий клиент, что удобно, потому что тогда у клиента есть ключ по умолчанию.

Когда это возможно, я стараюсь поддерживать единую идентичность для агрегатов. Я не уверен, требуется ли MongoDB дополнительный технический идентификатор, но если он требуется, а идентификатор домена нельзя использовать вместо него, тогда MongoDB должна управлять им самостоятельно и за кулисами.

person eulerfx    schedule 03.08.2012
comment
«действительность совокупности ортогональна идентичности». Конечно, в некоторых случаях агрегат должен иметь идентичность, прежде чем его можно будет назвать действительным? - person Geert-Jan; 03.08.2012
comment
Но на самом деле только идентификатор домена (который должен быть установлен на заводе, верно?), а не Технический идентификатор. До сих пор не могу понять, почему предпочтительно (хотя и не обязательно) иметь отдельный технический идентификатор в mongodb, но я думаю, что это совершенно другой вопрос - person Geert-Jan; 03.08.2012
comment
Назначенное значение идентификатора может указывать на то, что агрегат является постоянным, но достоверность отличается. Я, конечно, вижу взаимосвязь, я просто думаю, что к идентичности в этом отношении относятся по-особому... - person eulerfx; 03.08.2012