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

Question

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

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

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

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

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

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

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

Спасибо

Answer 1

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

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