repository - DDD 和 MVC : The Contoller gets the AggregateRoot from Factory not Repository? 是吧？

Question

我最近开始了一个使用现有数据库(Oracle)和 MVC 4 的项目。已经进行了很多编码..但是代码中没有“策略”..只有 DB -> ORM -> Controller。因此，我正在尝试为开发添加一些闪光，并练习一些 DDD 开发技术。

我已经定义了几个聚合根，每个都有一个存储库，用于处理保存和删除(及其子)等。这些聚合根中的一个引用了另一个聚合根，它通过它处理它的“子对象”它。

例子:

A Client has one or more purchase orders which has Line Items, 
if a client wants to add a line item to the purchase order, 
it has to go through the purchase order.

很好.. 客户 Aggregate Root，采购订单 Aggregate Root。

现在，一些服务也出现了，比如修改采购订单状态的服务，它消除了采购订单AR的负担，而且它很好、干净、有目的(它可以被其他“东西”用来更新采购订单的状态)，(也许这应该是采购订单 AR 的一部分？一个小细节..)

存储库目前正在做他们的工作，即从数据库中持久化数据并用数据“填充”AR。当 AR“保存”它时，存储库会保存任何需要保存的内容。客户 AR 使用采购订单存储库，因此客户可以加载它可能包含的任何采购订单。希望我走在正确的轨道上。

现在，进入MVC。所以我也有一些 ViewModel，它们基本上是关于需要向用户输出的内容的显示定义。 Automapper 已经证明 frickin AWESOME，所以我可以“自动映射”到 View 模型。不需要大脑，完美..

现在，真正让我失望的实现细节..

Controller 目前正在通过一个客户端工厂工作，它返回一个客户端 AR，然后它可以执行采购订单列表 Controller 需要做的任何事情，即管理相关的采购订单(作为一个整体，而不是采购订单的详细信息或本例中的数据)。

所以现在我想确保这是正确的..因为我看到的很多例子都有 Controller 与存储库而不是工厂一起工作，但我也看到工厂被推荐用于创建 AR ......这让我相信在示例中， Controller 正在处理聚合根，但是这种需要“消费者”的方式必须查询 AR 才能获取 AR:

像:

Get the Client Aggregate where the ClientID is 15

或者更好:

get the Client Aggregate, where the ClientID is 15 
and where active purchase orders > 0 ...or something..

这可能看起来像:

ClientAR = ClientRepository.GetClientByIDAndHasActivePurchaseOrders(15);
resultsImLookingFor = ClientAR.PurchaseOrders(); //or something

我觉得在这种情况下，存储库会根据我的需要“填充”ClientAR，所以现在我有了这个 ClientAR 东西，它根据它的使用情况而有所不同，它对我来说很臭……

使用工厂“感觉更好”，因为我只是从工厂创建一个 ClientAR 然后使用它，它不会根据情况而改变.. 它就是这样..

ClientAR  = ClientFactory.CreateClient(15) // returns a ClientAR 
resultsImLookingFor = ClientAR.GetPurchaseOrdersByStatus(statusID);

或者也许我完全想念它，我应该这样做::

ClientAR = ClientRepository.GetClientByID(15, PurchaseOrderSpec)

我错过了事物的规范方面吗？ (在这一点上，我还没有足够的能力真正开始使用规范(只是还)，因为我需要让这些东西正常工作)

我试图不陷入实现的细节，因为当然我的老板并没有对我是如何做到的......到目前为止，至少在考虑 DDD 的情况下实现事情(希望我得到它)已经证明非常好的可测试性和责任的逻辑“边界”，这是由这种“模式”或“思维方式”产生的，我想我应该说..

那么，我是否正确地接近这个？如果它是有争议的，我可以接受。如果它只是简单的错误，那么指导肯定是值得赞赏的，如果我离得很远，如果背后有充分的理由， build 性的批评不会伤害我的感情。

提前致谢。

Answer 1

So i'm trying to add some flare to the development as well as practice some DDD development techniques.

Flare 通常不是项目的理想品质，并且可能适得其反，导致首字母缩写词驱动开发、简历驱动开发等。DDD 也是如此 - 不要在不了解缺点的情况下尝试应用 DDD 战术模式。

one of these Aggregate Roots has reference to another Aggregate Root

AR 之间的引用应仅限于身份引用，而不是尽可能地引用对象。 AR 应该定义一个一致性边界，该边界不一定会导致模型以最自然的方式反射(reflect)现实。可以通过身份引用来表达客户和 PO 之间的关系 - PO 上有一个客户 ID。看看 Effective Aggregate Design by Vaughn Vernon了解更多信息。

maybe that should be a part of the Purchase Order AR?

实体状态的任何修改都应由实体封装。域服务可以为实体提供功能，而该功能不适合现有实体。

The repositories are currently doing their job of persisting the data from the database and "fills up" the AR's with data. when the AR "saves" it, the repository, saves anything that needs saving. The Purchase Order Repository is used by the Client AR so the client can load up any Purchase orders it may contain.. Hopefully I'm on the right track.

AR、实体或值对象都不应引用存储库或调用其上的任何方法。存储库应由应用程序服务调用。客户端 AR 不太可能包含 PO 集合。相反，客户的采购订单列表应由采购订单存储库提供。关系仍然存在，它只是使用存储库而不是对象遍历来实现。其原因可以追溯到 AR 是一个一致性边界。

The controller currently is working through a Client Factory

工厂应该只用于创建新实例，而不是访问持久化实例——这就是存储库的用途。您可以通过几种方式构建表示层 (MVC)。典型的 DDD 架构是让 Controller 引用应用程序服务。应用服务反过来通过协调存储库、工厂、基础设施服务和调用 AR 上的行为来实现特定的用例。假设您有一个客户创建新 PO 的用例。代码看起来像:

public ActionResult CreatePurchaseOrder(CreatePurchaseOrderViewModel viewModel)
{
   var poData = viewModel.CreatePurchaseOrderData();

   this.purchaseOrderAppService.CreatePurchaseOrder(viewModel.ClientId, poData);

   return RedirectToAction("Index");
}

...

public class PurchaseOrderAppService
{
  readonly IClientRepository clientDb;
  readonly IPurchaseOrderRepository poDb;

  public void CreatePurchaseOrder(int clientId, PurchaseOrderData poData)
  {
     var client = this.clientDb.Get(clientId);

     var purchaseOrder = PurchaseOrderFactor.Create(client, poData);

     this.poDb.Add(purchaseOrder);
     this.poDt.Commit(); // committing of Unit of Work should be moved up to infrastructure level
  }
}

看看这个 DDDSample.Net project其中包含 DDD 项目的 MVC UI 实现。