nhibernate - 域模型–存储库–跨子系统的通信

Question

我目前正在设计一个系统，该系统将使用多个数据源来消耗所需的数据。我正在尝试对下面显示的概念进行建模（会发布图像，但积分不足！），客户可以在其中与多种产品建立关联。客户将存储在“客户子系统”中，产品和客户产品将存储在“产品子系统”中

public class Customer
{
    public string FirstName { get; set; }

    public Guid ID { get; set; }
}
public class CustomerProduct
{
    public Guid ID { get; set; }

    public Customer Customer { get; set; }

    public Product Product { get; set; }
}
public class Product
{
    public string Name { get; set; }

    public double Price { get; set; }

    public Guid ID { get; set; }
}

“客户”实体将物理地保留在必须通过Web服务访问的系统中。使用NHibernate作为ORM，“ ConsumerProduct”和“ Product”实体将保存在SQL数据库中。

作为设计的一部分，我计划使用存储库从域模型中抽象出数据持久性技术。因此，我将有3个存储库接口，即ICustomerRepository，ICustomerProductRepository和IProductRepository。然后，我将为CustomerProduct和Product存储库创建一个具体的NHibernate实现，并为Customer存储库创建一个具体的Web服务访问实现。

我正在努力的是持久化在不同子系统中的实体之间的交互方式。理想情况下，我想要一个丰富的域模型，其中CustomerProduct实体将具有一个物理“ Customer”属性，该属性返回一个Customer对象。但是我不知道这将如何工作，因为需要从另一个数据存储区访问Customer实体。

我能看到的解决此问题的唯一方法是，不维护CustomerProduct实体中对Customer的完整引用，而是仅保留引用，然后每次需要获取Customer的引用时，我只会通过Customer仓库。

对于任何人可以提出的有关解决此问题的建议，我将不胜感激。

Answer 1

嗨，我以前没有遇到过这种情况，但是我已经设计了与其他子系统通信的域。
我没有整体情况，但是似乎客户实体与其他客户实体CustomerProduct和Product更加隔离。所以我猜对了，您将在一个通用的GUI中显示模型，但它只是分离的数据源吗？

首先，您可以通过不同的方式解决此问题，还应该问自己一些非功能性需求，例如维护，正常运行时间和支持。两个系统将始终同时启动并运行，还是会导致系统关闭。我要寻找的线索是您应该与子系统通信同步还是异步（消息排队？）。这可以通过使用NServiceBus来实现。

但是要专注于您的域，应该使域看起来像只有一个模型。这可以通过不同的方式来完成：

1）让ICustomerRepository（行为类似于对一组对象的接口契约）由与基础结构相关的存储库实现，该存储库会消耗子系统中的Web服务。提示您应将GUID用作键，以便发生键冲突。这种方法不会让您与其他实体的客户有任何关系/关联。他们只能通过存储库访问（吉米·尼尔森（Jimmy Nilsson）在他的书（http://jimmynilsson.com/blog/）中使用的一种解决方案，不会对许多双向关系加紧模型）。

2）取决于用例如何定位/使用模型，但是您可以创建一个应用程序范围的服务层，该服务层位于一个物理位置，但使用CustomerService和CustomerProcuctService和ProductService。为了防止域逻辑泄漏到应用程序层中，可以将这些实体之间的某些协调封装在域事件处理程序中，以协调不同服务之间的某些事件。

3）您还可以创建一个具有其他子系统CustomerGUID作为键的CustomerAdapter类（它不能生成键，因为Customer webservice可以控制该键）。但是您可以在Nhibernate中映射它，并在CustomerProduct和CustomerAdapter之间建立关系。但是，当您映射CustomerAdapter时，将仅加载GUID。然后确保使用Spring.Net Windsor或其他一些DI工具将ICustomerAdapterService注入到属性中。然后，您将不映射Nhibernate中的customerAdapter的属性（例如customername，adress等）。但是，当您从CustomerAdapter获取/读取Adress时，它将从ICustomerAdapterService获取并设置所有其他值。
不建议使用此解决方案，因为它会破坏某些DDD规则，例如在域模型中不提供服务。但是，如果从这个角度来看它：它实际上可以视为域服务，因为它可以解决分布式域中的问题。但是，它包括与基础结构相关的事物（例如WCF服务实现），因此该服务实现应位于另一个基础结构层/程序集中

最简单的解决方案2如果您可以处理以下事实，即客户实体只能由应用程序层中的服务访问。
但是，此应用程序服务层可以是两个子系统之间的良好反腐败层。今天有两个子系统可能是有原因的。
但是是一个交互流程的示例（没有您的域的详细知识）：


GUI调用应用程序服务CustomerProductService方法BuyNewProduct（CustomerDTO客户，ProductDTO newProduct）
CustomerProductService将ICustomerProductRepository和IProductRepository注入到构造函数中。它还将具有一个基础结构服务ICustomerFacadeService（现在更改名称为：-），该服务被注入到Property CustomerFacadeService中。该服务的创建由具有两种创建方法Create（）和CreateExtendendedWithCustomerService（）的工厂完成。后者还将注入CustomerServiceFacade
现在，方法BuyNewProduct（...）将组装CustomerDTO，并使用CustomerGUID从CustomerFacadeService加载客户，该客户将在另一个子系统中调用Web服务。
加载的客户将确保它确实存在，但是现在我们使用IProductRepository加载产品
使用CustomerGUID值和Product Entity，我们创建一个新的CustomerProduct实体（实际上只是Products和Customer GUID之间的映射类），并通过ICustomerProductRepository保存它
现在，您可以致电另一个基础架构服务，向您的客户发送一封电子邮件，该电子邮件将通知您它有权使用新产品。或者，您可以在CustomerProduct实体中创建Domain事件，该实体将此通知委托给在ctor中注入IEmailService的事件处理程序（在应用程序服务层中）。然后，当您将新客户连接到产品时，您就会迷失了发送通知的领域知识。


希望这可以帮助您以更少的痛苦来建模您的域。因为做DDD很痛苦。需要在镜子前与同事，领域专家和您自己进行很多讨论:)这是正确的道路吗？
在DDDsample.net上查找域事件，或搜索Udi Dahan和域事件。



我在这里写一个答案，有更多空间：

关于CustomerAdadpter，在交互流程示例中也称为CustomerFacadeService，这是我的看法：如何实现取决于您的应用程序。大多数用户会调用主系统来调用您的“云子系统”，这将具有良好的正常运行时间：-那么您可能不需要队列，并且云中将具有WCF服务。您的CustomerFacadeService将是一个服务包装程序，它仅公开您的应用程序层所需的方法，并组装所有必需的DTO对象。
如果您的云系统也将回调到您的主系统，那么您需要将某些方法公开为服务。然后，您可以选择将NServiceBus终结点公开为WCF服务。这使您可以在不丢失信息的情况下关闭主系统。
但是总是有很多屁股...
如果您的基础技术人员想要安装修补程序/重新启动主系统的Web服务器，则当然需要在另一台计算机上具有WCF服务。
如果您在主系统关闭时让客户等待响应，他们将等待多长时间？我猜不太长时间。
因此，我可以看到一种好处，那就是如果您有需要执行的批处理/报告，并且如果系统的一部分发生故障，那么一旦再次发生，报告将继续。

这是作为WCF服务公开的NServiceBus的一些示例。但是我没有做到这一点的经验，只有“可以做到”的知识。
http://docs.particular.net/nservicebus/architecture/nservicebus-and-wcf