我有点困惑。我刚刚看了Julie Lerman在Pluralsight上关于DDD的视频，以下是我的疑惑：
以一个简单的在线商店为例，其中包括： 采购订单中的商品供应商，那么这里的聚合根是什么？
从技术角度来看，采购订单是聚合根，对吧？它是针对特定的供应商并有商品。这是有意义的。
但是..物品本身也是聚合根吗？它还有其他“子对象”，如“品牌”，“设计师”，“颜色”，“类型”等...您可能在SOA系统中有一个单独的应用程序来编辑和管理物品（没有采购订单）。那么，在这种情况下，您将不得不访问聚合根的组件-这是不允许的。
在这个例子中，商品是聚合根吗？
这取决于你所处的上下文。我将尝试用几个不同的上下文例子来解释，并在最后回答问题。
假设第一个上下文是关于向系统添加新项目。在这种情况下，Item 是聚合根。您很可能会构建和添加新项目到您的数据存储或删除项目。让我们假设该类可能如下所示：
namespace ItemManagement
{
public class Item : IAggregateRoot // For clarity
{
public int ItemId {get; private set;}
public string Description {get; private set;}
public decimal Price {get; private set;}
public Color Color {get; private set;}
public Brand Brand {get; private set;} // In this context, Brand is an entity and not a root
public void ChangeColor(Color newColor){//...}
// More logic relevant to the management of Items.
}
}
现在假设系统的不同部分允许通过向订单中添加或删除项目来组成采购订单。在这种情况下，Item并不是聚合根，而且最好甚至不是相同的类。为什么呢？因为品牌、颜色和所有逻辑在这种情况下很可能完全不相关。以下是一些示例代码：
namespace Sales
{
public class PurchaseOrder : IAggregateRoot
{
public int PurchaseOrderId {get; private set;}
public IList<int> Items {get; private set;} //Item ids
public void RemoveItem(int itemIdToRemove)
{
// Remove by id
}
public void AddItem(int itemId) // Received from UI for example
{
// Add id to set
}
}
}
namespace Checkout
{
public class Item : IEntity
{
public int ItemId {get; private set;}
public string Description {get; private set;}
public decimal Price {get; private set;}
}
public class PurchaseOrder : IAggregateRoot
{
public int PurchaseOrderId {get; private set;}
public IList<Item> Items {get; private set;}
public decimal TotalCost => this.Items.Sum(i => i.Price);
public void RemoveItem(int itemId)
{
// Remove item by id
}
}
}
namespace warehousing
{
public class Warehouse : IAggregateRoot
{
// Id, name, etc
public IDictionary<int, int> ItemStock {get; private set;} // First int is item Id, second int is stock
public bool IsInStock(int itemId)
{
// Check dictionary to see if stock is greater than zero
}
}
}
每个上下文通过其自己版本的根和实体，公开执行其职责所需的信息和逻辑。无多余也无不足。
我知道你的实际应用程序会更加复杂，在将项目添加到采购订单之前需要进行库存检查等。重点是，你的根理想要已经加载完成所需的一切，而且没有其他上下文会影响在不同上下文中根的设置。
因此，回答你的问题——任何类都可以是实体或根，具体取决于上下文，如果你管理了好领域边界，那么你的根很少需要相互引用。你不必在所有上下文中重复使用相同的类。事实上，如果使用相同的类，通常会导致诸如User类长度为3000行，因为它具有管理银行账户、地址、个人资料详情、朋友、受益人、投资等逻辑。这些东西都不应该放在一起。
回答你的问题
命名空间名称反映您所在的上下文名称。因此，在项目管理的上下文中，Item是根并且放置在ItemManagement命名空间中。你也可以将ItemManagement视为聚合，Item作为该聚合的根。我不确定这是否回答了你的问题。
这完全取决于你上下文的内容。如果只用Item来显示价格和名称，则不需要公开逻辑，除非它确实在上下文中使用。例如，在CheckOut上下文示例中，Item没有任何逻辑，因为它们只是用于显示用户的购买订单包含哪些物品。如果有不同的功能，例如用户可以在结账时更改购买订单中物品的颜色（例如手机），则可能会考虑在该上下文中在物品上添加此类型的逻辑。
对不起，我假设你的系统使用某种ORM，例如(N)Hibernate或Entity Framework。在这种ORM的情况下，当根持久化时，ORM会自动将集合更新转换为正确的SQL（前提是您的映射已正确配置）。在您自己管理持久性的情况下，这会稍微复杂一些。直接回答问题-您可以将数据存储接口注入到根中，但我建议不要这样做。
你可以拥有一个存储库来加载和保存聚合。以具有Checkout上下文中物品的采购订单示例为例，你的存储库可能会像以下内容：
public class PurchaseOrderRepository
{
// ...
public void Save(PurchaseOrder toSave)
{
var queryBuilder = new StringBuilder();
foreach(var item in toSave.Items)
{
// Insert, update or remove the item
// Build up your db command here for example:
queryBuilder.AppendLine($"INSERT INTO [PurchaseOrder_Item] VALUES ([{toSave.PurchaseOrderId}], [{item.ItemId}])");
}
}
// ...
}
你的API或服务层看起来应该像这样：
public void RemoveItem(int purchaseOrderId, int itemId)
{
using(var unitOfWork = this.purchaseOrderRepository.BeginUnitOfWork())
{
var purchaseOrder = this.purchaseOrderRepository.LoadById(purchaseOrderId);
purchaseOrder.RemoveItem(itemId);
this.purchaseOrderRepository.Save(purchaseOrder);
unitOfWork.Commit();
}
}
如果这种情况发生，你的存储库可能会变得相当难以实现。实际上，删除采购订单上的项目并重新添加在PurchaseOrder根目录中的项目可能更容易（但不推荐）。每个聚合根都应该有一个存储库。
离题： 像（N）Hibernate这样的ORM将通过跟踪加载后根对象所做的所有更改来处理Save（PO）。因此，当你保存时，它将具有内部历史记录，记录根及其子项所做的每个更改，并发出适当的命令以使数据库状态与根状态同步，通过发出SQL语句来解决每个更改。
Item AR被称为 ItemManagement，但是PO AR只被称为 PurchaseOrder？2. 实体（如轻量级 Item）是否也应该有方法和逻辑呢？3. ARs 如何访问数据库？它们应该有一个接口...比如说 IPurchaseOrderData，其中包含像 void RemoveItem(int itemId) 这样的方法吗？它们仍然不会了解数据源。我将通过接口注入这些知识。因此，PurchaserOrder AR 的构造函数将是 public class PurchaseOrder (IPurchaseOrderData poData) { ... }。你同意吗？ - Ish ThomasIsInStock()方法。IsInStock是Item的公共方法，所以我想我没有违反DDD原则。是吗？ - Ish Thomas