c# - DDD - POCO。第一步

Question

这是我第一次使用 DDD。在公司里，我们没有“域管理员”。我只读过 DDD 我需要用 DDD 方法实现域。

所以，我知道在域中没有数据库功能的位置。但是如果我将我的域与 Entity Framework 和 NOSQL 数据库一起使用。使用 EF 我需要使集合虚拟化，并在构造函数中分配为新的。这在 DDD 中不好吗？

我的代码:

 public abstract class Merchant : AggregateRoot
{
    public Company Company { get; set; } // Entity

    public string CIF { get; set; }
    public string NIP { get; set; }
    public string Status { get; set; }

    public Address Address { get; set; } // Entity
    public Group Group { get; set; } // Entity
    public virtual ICollection<Brand> Brands { get; set; } // Brand is entity

    protected Merchant()
    {
        this.Brands = new List<Brand>();
    }
}

Answer 1

有multiple shades of opinion关于 DDD 空间中的这个问题。

对我来说，“持久性无知”的主要衡量标准是:

Will a change in my database break things in my domain layer, forcing me to open up the domain model and modify stuff to fix it ?

如果我们看一下您的示例，答案显然是否定的。

如果您的实体类中有引用表名或列名的数据注释，或者您依赖于约定映射并更改 Merchant 表名到数据库中的 Reseller。但是拥有默认构造函数和虚拟属性并不会使您的域类在面对数据库更改时更加脆弱。

然后你有一个次要问题，一个不太重要的 IMO 问题:

Is the ORM a hindrance in my implementing domain entities just the way I want and as DDD-compliant as they need to be ?

这个有点挑战。如果 ORM 强制您添加可能使域对象处于不一致状态的操作，则可能是这样。不过，我不认为无参数构造函数容易出现这种情况，因为它可以是私有(private)的，因此不可能搬起石头砸自己的脚。与二传手相同。

有些人认为像需要虚拟和无参数构造函数这样的小痕迹违反了 DDD，因为你的实体不再是纯粹的，它们包含由 ORM 的存在引起的奇怪之处。因此，您应该创建第二个“持久性”模型以使域模型不受污染。我不。我认为大多数时候不值得在复杂性方面进行权衡 - 只要坚持无知的第一条规则成立，您就可以忍受这些小怪癖。