DDD - 聚合根 - 示例订单和订单行 [英] DDD - Aggregate Root - Example Order and OrderLine

查看:174
本文介绍了DDD - 聚合根 - 示例订单和订单行的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在努力学习 DDD(通过开发一个示例电子商务网站,其中包含 OrderOrderLinesProductCategories 等).根据我对聚合根概念的理解,我认为 Order 类应该是 OrderLine 的聚合根.

I am trying to get my hands dirty learning DDD (by developing a sample eCommerce site with entities like Order, OrderLines, Product, Categories etc). From what I could perceive about Aggregate Root concept I thought Order class should be an aggregate root for OrderLine.

到目前为止一切顺利,但是当它从 UI 定义创建订单流时我很困惑.当我想向我的订单对象添加订单行时,我应该如何获取/创建 OrderLine 对象的实例:

Things went fine so far, however I am confused when it define a create order flow from UI. When I want to add an order line to my order object, how should I get/create an instance of an OrderLine object:

  1. 我是否应该在我的 UI/Service 类中硬编码新的 OrderLine() 语句
  2. 我是否应该在Order 类中定义一个带有productIDquantity 等参数的方法?
  1. Should I hardcode the new OrderLine() statement in my UI/Service class
  2. Should I define a method with parameters like productID, quantity etc in Order class?

此外,如果我想使用 DI 从 UI 或 Order 类中删除硬编码实例怎么办.最好的方法是什么?

Also, what if I want to remove the hardcoded instantiations from the UI or the Order class using a DI. What would be the best approach for this?

推荐答案

据我所知聚合根概念我认为顺序类应该是一个聚合根订单行.

From what I could perceive about Aggregate Root concept I thought Order class should be an aggreagrte root for OrderLine.

是的,OrderLine 最有可能位于 Order 根目录下,因为 OrderLine 在父 Order 之外可能没有任何意义.

Yes, OrderLine's should most likely be under an Order root, since OrderLine's likely make no sense outside of a parent Order.

我应该硬编码新的 OrderLine()我的 UI/Service 类中的语句

Should I hardcode the new OrderLine() statement in my UI/Service class

可能不会,尽管这是它经常发生的方式,并且可以正常工作.在我看来,问题在于对象构造经常发生在不同的上下文中,并且验证约束因上下文而异.

Probably not, though this is how it happens often and it is made to work. The problem, as I see it, is that object construction often happens in different contexts, and the validation constraints differ depending on that context.

我应该定义一个方法产品ID、数量等参数在订单类?

Should I define a method with parameters like productID,quantity etc in Order class?

如:

public OrderLine AddOrderLine(Product product, int Quantity ... )

这是一种方法.请注意,我使用了 Product 类而不是 ProductId.有时一种比另一种更可取.我发现出于各种原因,我经常使用这两者 - 有时我有 ID,但没有充分理由提取聚合根,有时我需要另一个根来验证操作.

This is one way to do it. Notice I used a Product class instead of a ProductId. Sometimes one is preferable to the other. I find I use both a lot for various reasons - sometimes I have the ID and there's no good reason to pull the aggregate root, sometimes I need the other root to validate the operation.

我这样做的另一种方法是为孩子们实现一个自定义集合.

Another way I do this is to implement a custom collection for the children.

所以我有:

order.OrderLines.Add(product, quantity);

这感觉更自然或 OO,特别是如果实体根有许多子集合,它可以避免混乱.

This feels a little more natural or OO, and in particular if an entity root has many child collections it avoids clutter.

order.AddOrderLine(), order.AddXXX(), order.AddYYY(), order.AddZZZ()

对比

order.OrderLines.Add(), order.ZZZs.Add(), order.YYYs.Add()

另外,如果我想删除来自 UI 的硬编码实例或使用 DI 的 Order 类.什么会是最好的方法吗?

Also, what if I want to remove the hardcoded instantiations from the UI or the Order class using a DI. What would be the best approach for this?

这将是工厂模式的教科书案例.我将这样一个工厂注入到我的自定义集合中,以支持那些 Add() 方法中的实例化.

This would be a textbook case for the Factory pattern. I inject such a Factory into my custom collections to support instantiation in those Add() methods.

这篇关于DDD - 聚合根 - 示例订单和订单行的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆