Обобщение общих объектов в DDD

Question

В моей системе есть некоторые общие объекты и объекты, и я просто хочу их обобщить, чтобы улучшить управление.

Я разрабатываю крупномасштабное приложение с различными видами агрегатов и контекстов, и я сопоставляю агрегаты домена с помощью свободного nhibernate. У меня есть разные виды тега в моей системе:

ProductTag 
BlogTag 
NewsTag 

, а также имеет ту же историю о категории, комментариях и ... сейчас я просто хочу, чтобы сделать свой род обобщение в базе данных, чтобы иметь список все теги, категории и комментарии ... теперь неплохо создать агрегат для каждого из них (тег, категория, ...) и иметь целую таблицу для них в базе данных, а затем создать соединение между другими тегами или категориями (Я имею в виду, что другие - productTag, BlogTag, ...)

У меня есть все эти теги как объект значения, как я могу получить экземпляр объекта значения в другом агрегированном корне? productTag (VO) в теге (совокупный корень)).

Мне нужно улучшить управление этими объектами. Я думаю, что лучший способ справиться с этим - создать целую совокупность для каждого из них, что вы думаете?

Answer 1

после обсуждения с одним из моих коллег я обнаружил, что нет необходимости обобщать эти сущности, и есть много различий между проблемой домена и проблемой базы данных. В первую очередь невозможно сделать объект ценности в качестве ссылки в другом сводном корне (совокупные корни могут иметь ссылку на другие корни совокупности). Я просто хотел решить проблему с базой данных с помощью концепций дизайна, основанных на доменах, поскольку упомянутый выше @StevePuder также не нужно делать что-то вроде этого, если вам не нужно перечислять их в пользовательском интерфейсе. , хотя мне нужно перечислить список тегов продукта, категории продуктов, тегов блога и ...в пользовательском интерфейсе, но мне не нужно совместно использовать их отдельно в другой таблице на сервере sql! для этого я могу просто создать службу запросов для извлечения тегов продукта и ... , поэтому нет необходимости делать экономически эффективные и неправильные вещи только потому, что для работы с базой данных проще сделать операцию запроса!

Answer 2

... теперь я просто хочу, чтобы сделать своего рода обобщения в базе данных, чтобы иметь список всех тегов, категорий и комментарии ...

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

Однако, если для этих объектов значений действительно нужен общий интерфейс (например, когда бизнес-правила должны знать все теги в системе), то эта концепция должна отражаться в вашей модели домена, а не только в база данных.

Лично я бы предпочел реализацию на основе domain events. Каждый агрегат будет генерировать собственное событие (ProductTaggedEvent, BlogTaggedEvent, NewsCommentedEvent, ...), содержащее всю необходимую информацию о конкретном объекте значения в контексте его совокупности. Отдельный компонент (другой совокупный или даже ограниченный контекст) будет слушать эти события и создавать специализированную модель, содержащую все теги/категории/комментарии в структуре, которую можно легко запросить. Он может сохраняться в одной и той же базе данных вместе с вашими другими агрегатами или даже в другом репозитории с совершенно другим механизмом хранения (как это обычно делается с помощью самых CQRS). В любом случае, нет необходимости обобщать что-либо, если вы создадите вторую модель/концепцию, специализированную для нужд, например. ваш пользовательский интерфейс.