Как я могу смоделировать эту иерархию объектов в Fluent NHibernate без нарушения принципов DDD?

Question

Я пытаюсь создать модель домена, которая позволит мне управлять контрактами.

Класс Contract - это мой совокупный корень, и сейчас у него есть единственное свойство - Reviewers.

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

База данных, к которой я привязываю модель моего домена, уже существует, и это устаревшая система, которую яЯ пытаюсь расширить.

У него есть таблица контрактов и таблица рецензентов.

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

Я смог легко сопоставить свою таблицу контрактов с FNH.

Она выглядит примерно так:

public class ContractMapping: ClassMap<Contract>
{
    public ContractMapping()
    {
        Id(c => c.Id);
        HasMany(c => c.AdditionalReviewers);
    }
}

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

public class Reviewer: User
{
    public virtual Guid Id { get; set; }

    public virtual Contract Contract { get; set; }
}

public class User
{
    public virtual Guid Id { get; set; }

    public virtual string Login { get; set; }
    public virtual string FirstName { get; set; }
    public virtual string LastName { get; set; }        
}

Я смог правильно сопоставить свой класс User, и он выглядит примерно так:

public class UserMapping: ClassMap<User>
{
    public UserMapping()
    {
        Id(u => u.Id);
        Map(u => u.Login);
        Map(u => u.FirstName);
        Map(u => u.LastName);
    }
}

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

public class ReviewerMapping: SubclassMap<Reviewer>
{
    public ReviewerMapping()
    {
        Table("Reviewer");

        //Id(r => r.Id).Column("ReviewerId"); <- won't compile
        References(r => r.Contract).Column("ContractId");
    }
}

Итак, у меня проблема в следующем:

Отношение между таблицей User и таблицей Reviewer одно к многим.Это означает, что для данного пользователя может быть много записей Reviewer.Зачем?Потому что пользователь должен быть рецензентом для конкретного контракта.Это вызывает проблему с отображением, потому что первичный ключ для моего Reviewer и первичный ключ для моего пользователя являются совершенно разными значениями по необходимости.

Кроме того, из-за способа, которым я использую Reviewer,когда я создаю нового Рецензента, я действительно пытаюсь связать Пользователя с Контрактом.Я не пытаюсь создать в базе данных совершенно нового Пользователя.

Как мне правильно сопоставить Reviewer, зная, что в моей доменной модели это подкласс User?

Answer 1

Похоже, рецензент на самом деле не моделирует человека, а моделирует роль или задание, которое берет на себя пользователь.Я бы сказал, что ваша модель домена имеет недостатки в этом аспекте.Tweak Reviewer - это ассоциативный класс между Пользователем и Контрактом.

Answer 2

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

Если это поможет вам лучше понять концепцию, переименуйте Reviewer в Review.Таким образом, вы можете перестать думать об этом как о Пользователе, поскольку это действительно не так (несколько Рецензентов в вашем текущем домене могут быть одним Пользователем, что не имеет особого смысла).