在C#存储库中应用DDD原则

我有一个相对简单的域模型，如图所示。我希望在DDD定义的域对象中维护此逻辑

每个域对象都是一个抽象类，只包含其各自的成员和域逻辑。这些类的具体实现由存储库返回，并提供给服务（使用DI）

我遇到的困难是理解如何处理创建新实体所需的情况。例如，域逻辑规定：

可以将帐户添加到

组

（创建

成员

实体）

• 将帐户添加到组时，新的

  成员

  实体的

  值

  属性必须设置为已在

  组中的成员总数

• 团队中的每个其他成员都必须有自己的价值 增加1

我可以在

组

上以

成员AddMember（Account Account）

方法实现此功能。但是，此方法需要实例化一个新的

成员

，以添加到组的成员集合中

由于域对象没有对应用程序中更上层的层的引用，并且域对象本身是抽象的，因此我不确定如何构建新的成员实例

我已经考虑过在具体实现可以实现的

组

对象上定义

抽象受保护成员CreateMember（）

方法的可能性，但这对我来说似乎很混乱，我担心我可能误解了更基本的东西

在努力遵守DDD原则的同时，我将如何实现这个模型

---

您可能想创建一个MemberFactory（作为域服务），负责创建新的成员对象。请参阅此示例。

我认为这里的基本问题是您的域对象是抽象的。域对象几乎总是具体的类（尽管有一些例外），它们实现所有必要的域逻辑

存储库只是外部数据源（如数据库）的接口，不应影响域的工作方式。通过让存储库返回对象的实际实现，您将域逻辑与存储库耦合起来

---

您应该重新考虑您的设计，使您的实体成为具体的类。总之，您的域对象应该实现所有域逻辑，而不考虑外部服务/存储库。

感谢您的回答。我的理解是，返回具体对象允许我实现持久性或延迟加载等行为，而不会污染域对象本身。这似乎并没有偏离大多数ORMs用来实现存储库的代理模式。在这个场景中，我希望减少在基础设施之外实例化新域对象的机会，从而使对象抽象化。正如@Steve Czetty所建议的，传递工厂和存储库似乎是一个可接受的解决方案。@SamGreenhalgh：通过将存储库接口注入到具体的域对象中，可以实现延迟加载。事实上，通过将类抽象化，实际上会对它们造成更大的污染，因为具体实现必须实现持久性以及域逻辑。显然，域逻辑是从抽象中继承的，因此不需要（或者如果没有标记为虚拟的话）由具体实现来实现？显然，域对象不应该实现持久性，这不是基础设施的问题吗？如果我想从使用NHibernate更改为实体框架以实现持久性，会发生什么情况？@SamGreenhalgh：是的，但这是继承与组合的经典案例，以及继承以添加持久性功能（与域对象无关）是否有意义。如果您注入一个存储库接口，域对象独立于实现——实际的存储库实现将在加载域对象时将自身注入域对象。感谢您的回复，它们非常有建设性。我已经接受了Steve Czetty的回答，因为我已经实施了似乎有效的工厂。