Вот мой взгляд на то, как я могу решить проблему такого типа тем способом, которым я в настоящее время практикую DDD.
Если вы редактируете что-то, что требует добавления и удаления тегов, например сообщения, тогда теги могут быть объектами, но, возможно, они могут быть объектами значений, и в любом случае загружаются и сохраняются вместе с сообщением. Я лично предпочитаю объекты-значения, если объект не нуждается в изменении, но я понимаю, что существует разница между объектами-сущностями, смоделированными как «моментальные снимки» только для чтения, и реальными объектами-значениями, которым не хватает идентичности. Сложность заключается в том, что, возможно, иногда то, что вы обычно считаете ключом, может быть частью объекта-значения, если оно не используется в качестве идентификатора в этом контексте, и я думаю, что теги попадают в эту категорию.
Если вы редактируете сами теги, то, вероятно, это отдельный ограниченный контекст или, по крайней мере, отдельный агрегат, в котором сами теги являются корнем агрегата и сохраняются через репозиторий. Обратите внимание, что класс сущностей, который представляет теги в этом контексте, не обязательно должен быть тем же классом сущностей, что и для тегов, используемых в агрегации сообщений.
Если вы перечисляете доступные теги на дисплее только для чтения, например, для предоставления списка выбора, то это, вероятно, список объектов-значений. Эти объекты-значения могут, но не обязательно должны быть в модели домена, поскольку они в основном связаны с поддержкой пользовательского интерфейса, а не с фактическим доменом.
Пожалуйста, откликнитесь, если у кого-нибудь есть какие-либо мысли о том, почему мой взгляд на это может быть неправильным, но я делаю это именно так.
person
jpierson
schedule
03.12.2012
