Question

在观看了Jimmy Bogard（http://ndcoslo.oktaset.com/Agenda）的NDC12演示文稿“Crafting Wicked Domain Models”之后，我在徘徊如何坚持这种领域模式。
这是演示文稿中的示例类：

public class Member
{
    List<Offer> _offers;

    public Member(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
        _offers = new List<Offer>();
    }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public IEnumerable<Offer> AssignedOffers { 
        get { return _offers; }
    }

    public int NumberOfOffers { get; private set; }

    public Offer AssignOffer(OfferType offerType, IOfferValueCalc valueCalc)
    {
        var value = valueCalc.CalculateValue(this, offerType);
        var expiration = offerType.CalculateExpiration();
        var offer = new Offer(this, offerType, expiration, value);
        _offers.Add(offer);
        NumberOfOffers++;
        return offer;
    }
}

因此该域模型中包含一些规则：
- 会员必须拥有姓氏和姓氏 - 外面的商品数量不能更改
- 会员负责创建新优惠，计算其价值和分配

如果尝试将其映射到某些ORM（如Entity Framework或NHibernate），它将无效。那么，使用ORM将这种模型映射到数据库的最佳方法是什么？例如，如果没有setter，如何从DB加载AssignedOffers？

只有对我有意义的是使用命令/查询架构：查询总是使用DTO作为结果，而不是域实体，并且命令在域模型上完成。此外，事件采购非常适合域模型上的行为。但是这种CQS架构并不适合每个项目，特别是棕色区域。或者不是？

我在这里知道类似的问题，但找不到具体的例子和解决方案。

Answer 1

这实际上是一个非常好的问题，我已经考虑过了。创建完全封装的正确域对象（即没有属性设置器）并使用ORM直接构建域对象可能很困难。

根据我的经验，有3种方法可以解决这个问题：

正如Luka已经提到的，NHibernate支持映射到私有字段，而不是属性设置器。
如果使用EF（我认为不支持上述内容），您可以使用memento pattern将状态恢复到域对象。例如您使用实体框架填充您的域实体接受的“memento”对象来设置其私有字段。
正如您所指出的，将CQRS与事件源一起使用可以消除此问题。这是我制作完美封装的域对象的首选方法，它还具有事件源的所有附加好处。

Answer 2

旧线程。但是Vaughn Vernon的more recent post（2014年末）只针对这种情况，特别是实体框架。鉴于我在某种程度上难以找到这样的信息，也许在这里发布它也会有所帮助。

基本上帖子提倡Product域（聚合）对象包装ProductState EF POCO数据对象，以关注＆＃34;数据包＆＃34; 事情的一面。当然，域对象仍然会通过特定于域的方法/访问器添加其所有丰富的域行为，但是当它必须获取/设置其属性时，它将使用内部数据对象。

直接从帖子中复制片段：

public class Product
{
  public Product(
    TenantId tenantId,
    ProductId productId,
    ProductOwnerId productOwnerId,
    string name,
    string description)
  {
    State = new ProductState();
    State.ProductKey = tenantId.Id + ":" + productId.Id;
    State.ProductOwnerId = productOwnerId;
    State.Name = name;
    State.Description = description;
    State.BacklogItems = new List<ProductBacklogItem>();
  }

  internal Product(ProductState state)
  {
    State = state;
  }

  //...

  private readonly ProductState State;
}

public class ProductState
{
  [Key]
  public string ProductKey { get; set; }

  public ProductOwnerId ProductOwnerId { get; set; }

  public string Name { get; set; }

  public string Description { get; set; }

  public List<ProductBacklogItemState> BacklogItems { get; set; }
  ...
}

Repository将使用内部构造函数，以便从其DB持久化版本中实例化（加载）实体实例。

我可以自己添加的一点是，可能Product域对象应该脏了与另外一个访问者只是为了通过EF持久化：同样是{ {1}}允许从数据库加载域实体，相反的方式应允许通过以下内容：

new Product(productState)

Answer 3

对于AssignedOffers：如果查看代码，您会看到AssignedOffers从字段返回值。 NHibernate可以像这样填充该字段：Map（x =＆gt; x.AssignedOffers）.Access.Field（）。

同意使用CQS。

Answer 4

首先进行DDD时，忽略持久性问题。 ORM与RDBMS紧密相关，因此它是一个持久性问题。

ORM建模持久性结构而不是域。基本上，存储库必须将收到的聚合根“转换”为一个或多个持久性实体。有界上下文很重要，因为聚合根根据你想要完成的内容而改变。

假设您要在分配的新要约的上下文中保存成员。然后你会有这样的事情（当然这只是一种可能的情况）

public interface IAssignOffer
{
    int OwnerId {get;}
    Offer AssignOffer(OfferType offerType, IOfferValueCalc valueCalc);
    IEnumerable<Offer> NewOffers {get; }
}

public class Member:IAssignOffer
{
    /* implementation */ 
 }

 public interface IDomainRepository
 {
    void Save(IAssignOffer member);    
 }

接下来，repo将只获得所需的数据，以便更改NH实体，这就是全部。

关于EVent Sourcing，我认为您必须看看它是否适合您的域名，我认为使用Event Sourcing仅用于存储域聚合根，而其余（主要是基础架构）可以存储在普通中时没有任何问题方式（关系表）。我认为CQRS在这个问题上给你很大的灵活性。

具有行为和ORM的丰富域模型

4 个答案: