Стоит ли моделировать ключевые слова как объект-значение в агрегированном продукте?

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

public class Product : Entity<Guid,Product> , IAggregateRoot
{
    public Guid AccountId { get; protected set; }

    public string Title { get; protected set; }

    public DateTimeOffset AddingDate { get; protected set; }

    public decimal Price { get; protected set; }

    public string Brand { get; protected set; }

    public string Description { get; protected set; }

    public IList<Keyword> Keywords { get; protected set; }
}

public class Keyword : ValueObject<Keyword> 
{
    public Keyword(string title) 
    {
        this.Title = title;
    }

    public string Title { get; protected set; }
 }

В зависимости от entity-vs -value-object-the-ultimate-list-of-differences Объекты-значения имеют несколько характеристик:

1. Два объекта-значения считаются равными, если они имеют одинаковые значения атрибутов.
2. Объекты-значения имеют нулевой срок службы.
3. Объекты-значения неизменяемы.

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

Итак, я стремлюсь смоделировать ключевое слово как объект значения, потому что меня не волнует его идентичность (будь то автоматически сгенерированное целое число или Guid) и пометка двух ключевых слов как равных по их атрибуту (который здесь заголовок).

Мой вопрос: Должен ли я моделировать ключевое слово как объект значения или сущность в зависимости от сценария выше и почему?

Изменить:

В зависимости от статьи, которую я предоставил выше:

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

Ключевое слово следует рассматривать как сущность (но я думаю, что модели домена и базы данных не должны зависеть друг от друга)


c# aggregate domain-driven-design value-objects
person Simple Code    schedule 20.10.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я не думаю, что стал бы беспокоиться даже о ключевых словах в домене.

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

В любом случае вы можете «управлять» ключевыми словами отдельно в своем пользовательском интерфейсе.

Вы можете пойти еще дальше и довольно легко иметь общий (возможно, поддомен) «репозиторий» Tag/Keyword, где любой Id (скажем, Guid) может иметь список ключевых слов или тегов. Таким образом, вы можете связать ключевые слова с чем угодно.

Чтобы довести это до крайности, общая система классификации может быть даже полезна... но это уже другая тема :)

person Eben Roux    schedule 21.10.2018
comment
да, я согласен с вами в том, что у них нет никаких бизнес-правил, но они являются частью совокупности продуктов, и в пользовательском интерфейсе, когда продавцу нужно добавить новый продукт в свой магазин, он должен предоставить их (амазон делает это) - person Simple Code; 21.10.2018
comment
Ваш пользовательский интерфейс может собирать все виды данных, но то, как вы собираете, храните и связываете эти биты, может быть разработано по-разному. Вполне возможно получить ключевые слова и закинуть их в какое-нибудь хранилище данных, которое связывает продукт с ключевым словом. Но дизайн должен быть просто разумным. Если бы вы, например, собирались связать ключевые слова с различными сущностями (мой пример, а не ваш), то наличие списка ключевых слов для каждого класса сущностей стало бы несколько болезненным ИМХО. - person Eben Roux; 21.10.2018
comment
Вы имели в виду, например, что я должен проверить инварианты продукта, а затем после его добавления я могу добавить связанные ключевые слова, используя репозиторий, чтобы ключевые слова не входили в совокупность продуктов?? и почему вы не возражаете против того, чтобы ключевые слова были как многие ко многим с таблицей продуктов? - person Simple Code; 21.10.2018
comment
Да, это именно то, что я имею в виду. Вы можете добавить ключевые слова отдельно и, возможно, даже сохранить их отдельно. Как и здесь, на SO, где мои просматриваемые теги хранятся отдельно от моего профиля. Они, безусловно, по-прежнему связаны с моим профилем и могут даже быть на странице профиля, но мне не нужно редактировать свой профиль, чтобы поддерживать этот список. Я не возражаю против того, чтобы ключевые слова были как многие ко многим :) --- так и получится, но, поскольку ключевое слово не является сущностью, оно на самом деле не является многими ко многим в традиционном смысле. Продукт просто имеет список ключевых слов... - person Eben Roux; 21.10.2018
comment
Тем не менее, тег вполне может быть сущностью. На SO они есть на самом деле. У них есть описание, которое может меняться со временем и т. д. - person plalx; 21.10.2018

arrow_upward
0
arrow_downward

Вы можете определить предикаты как аргументы для методов поиска. И поставить предикаты относительно агрегата в модуль агрегата (модуль как понятие DDD), т.е. java или пространство имен в вашем случае (не уверен, что в терминологии Microsoft это называется пространством имен, я пришел из мира java).

В любом случае, если вы не используете предикаты, вы можете создать объект значения с ключевыми словами для поиска (например, DTO), и он будет жить в том же модуле, что и агрегат.

Надеюсь, это объяснение поможет.

person choquero70    schedule 27.10.2018