如何在不违反DDD原则的情况下，在Fluent NHibernate中对该对象层次结构建模？

我试图建立一个域模型，使我能够管理合同

契约类是我的聚合根，它现在只有一个属性，即Reviewers

在合同的上下文中，每个审阅者都有其父合同的属性，以及名字、姓氏和登录名。他们拥有这些属性的原因是，我可以让用户选择他们希望在合同中使用的审阅者

我将我的域模型绑定到的数据库已经存在，并且它是我试图扩展的遗留系统

它有一个合同表和一个审阅者表

到目前为止，我还没有提到的是，评论者实际上是系统中的用户。所以实际上涉及到第三个表，即用户

我已经能够很容易地将我的合同表映射到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; }        
}

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

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

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

我已经能够正确地映射我的用户类，它看起来像这样：

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; }        
}

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

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

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

公共类用户映射：类映射 { 公共用户映射（） { Id（u=>u.Id）； 映射（u=>u.Login）； Map（u=>u.FirstName）； Map（u=>u.LastName）； } } 我相信我想像这样映射我的Reviewer类：

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; }        
}

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

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

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

公共类映射：子类映射
{
公共地图（）
{
表（“审核人”）；
//Id（r=>r.Id）.列（“审阅者Id”）听起来像是一个例子。在你描述的场景中，Reviewer并不是真正的为一个人建模，而是为用户承担的角色或任务建模。我认为你的域模型在这方面是有缺陷的。将Reviewer调整为用户和合同之间的关联类。
我认为Reviewer不应该从用户继承。我希望Reviewer类保留一个用户对象（组合重于继承）

如果这有助于你更好地将其概念化，请将Reviewer重命名为Review。这样，你就可以不再将其视为一个用户，因为它实际上不是（当前域中的多个审阅者可以是同一个用户，这没有多大意义）.
我本来就是这样的，但对我来说，有一个名为Reviewer的类，然后让它包含一个用户属性似乎很奇怪，从DDD的角度来看，这似乎是错误的。从DDD的角度来看，我需要我的合同能够添加和删除审阅者。合同可以添加的审阅者是系统中的用户，而ough.我明白你的意思，但是我为这个问题设置的域上下文边界只使用一个合同设置。在这种情况下，同一个用户不能有多个审阅者。这只存在于我当前的域上下文之外（因为我想我正在处理一个遗留系统）。也许从DDD的角度我没有掌握域上下文的某些方面。@Joseph问题：为什么不让每个契约都有一个用户列表，而不是这个额外的Reviewer类，它不包含任何内容？如果它确实包含信息，比如审阅数据本身，那么我仍然认为将该类重命名为review and having it将用户作为其属性之一是对该域建模的正确方式。在我进入下一个任务时，它将拥有额外的数据，即跟踪系统中的哪个用户实际将审阅者分配给了合同。我确实花了更多的时间考虑这一点，我认为你的想法是正确的，但对于我的域，我认为将User类更改为UserAccount类更为正确，而不使用Reviewer类。通过将其更改为UserAccount，我认为它澄清了实际发生的情况。