domain-driven-design - 在 DDD 中的聚合根上创建子实例

标签 domain-driven-design

我一直在阅读 Eric Evan 关于 DDD 的书,在第 139 页他说:

“如果您需要在预先存在的 AGGREGATE 中添加元素,您可以在 AGGREGATE 的根目录上创建一个 FACTORY METHOD”

我假设可以这样实现,其中方法 NewLineItem 用于创建新订单项并将其添加到订单。

class Order
{
   public IEnumerable<LineItem> LineItems { get; }

   public void NewLineItem(Product product, int quantity);
}

我能想到的另一种方法是将工厂方法移到集合本身中。像下面这样的东西。然后我可以通过调用 LineItems.New(...) 添加一个新项目。

class Order
{
   public LineItems LineItems { get; }

   public class LineItems : IEnumerable<LineItem>
   {
       public void New(Product product, int quantity);
   }
}

每种方法的优缺点是什么?将工厂方法移动到集合中是否有任何问题?我们目前正在尝试找出实现大型领域模型的最佳方法。我们担心其中一些根聚合模型会因大量工厂方法和删除方法(例如 RemoveLineItem(LineItem))而变得臃肿。我们的想法是,将这些工厂方法移动到它们的集合中有助于组织设计并使根聚合减少方法的困惑。有什么建议吗?

谢谢

最佳答案

直接在 AR 上使用工厂方法的一个优点是,它使 AR 知道更改并允许它强制执行它的不变量。不仅如此,由于该方法了解 AR 的内部状态,您可以减少传递给工厂方法的参数数量(在创建其他相关 AR 时最有用)。

例如registration = course.register(registrant)registration = new Registration(registrant, courseId)

此外,LineItem 成为一个实现细节,因此客户端不需要知道该类。

您问这个问题并且实际上担心您的 AR 上有太多方法这一事实可能表明您可能将不属于一起的对象聚集在一起。

不要忽视 AR 的主要目的:它是一个允许保护不变量的事务边界。如果没有要保护的不变量,那么聚类可能是不必要的,甚至是不可取的。

我强烈建议您阅读 Effective Aggregate Design作者:Vauhgn Vernon。

关于domain-driven-design - 在 DDD 中的聚合根上创建子实例,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33851581/

相关文章:

dns - 使用非英语无处不在的语言?

c# - 如何避免领域模型中的持久化逻辑?

domain-driven-design - DDD - 如何处理 "returning domain events"模式中的事务?

.net - 存储库或数据访问方法中的方法上的 'Find' 和 'Get' 动词有什么区别?

domain-driven-design - 聚合是否必须高度一致?

java - 如何避免存储库和域层的重复?

oop - 避免抽象类和继承

java - Java 中的域事件模式实现?

object - DDD - 聚合根 - 订单和订单行示例

domain-driven-design - 领域驱动设计和安全