有可能(甚至很可能)我只是没有完全理解“工作单元”的概念。基本上，我将其视为面向对象环境中使用的一种广泛事务。启动工作单元，与对象交互，提交或回滚。但这如何分解为这些对象背后的数据存储上的实际事务呢？
在具有单个 DB 和 ORM(例如 NHibernate)的系统中，这很容易。事务可以通过 ORM 维护。但是对于一个自定义域模型掩盖了许多不同数据源的系统呢？并非所有这些数据源都是关系数据库？ (这里的文件系统做了很多工作。)
现在，我坚持这样的想法:“您根本无法在同一个‘原子’业务操作中维护跨 SQL2005 DB、SQL2000 DB、DB2 DB 和文件系统的事务。”因此，目前团队中的开发人员(通常彼此独立工作)有责任在代码中手动维护事务。每个数据库上都可以有适当的事务，但是整个业务操作在每个重要步骤中都是手动检查和平衡的。
然而，随着领域复杂性的增加和标准开发人员的流动性，这种方法将随着时间的推移变得越来越困难和容易出错。
是否有人对如何最好地处理这样的域或以前如何处理过这样的域有任何建议或示例？在这种情况下，实际的“领域”仍处于起步阶段，作为原型(prototype)演变为有朝一日扩展和使用/替换由不同遗留应用程序组成的大型生态系统。因此，有足够的空间进行重新设计和重构。
作为引用，我目前针对的设计的 10,000 英尺 View 是: 大量小型客户端应用程序调用基于消息的中央服务。该服务是进入“领域核心”的入口，可以被认为是一个大型 MVC 风格的应用程序。向服务发出请求(很像“ Action ”)，由处理程序(很像“ Controller ”)接收。任何程序都在那里。它们与包含所有业务规则的模型交互。模型通过与存储库(数据库 x、数据库 y、文件系统、电子邮件、任何外部资源)交互来发布事件，监听器(“服务”？这部分在设计中仍然很模糊，需要改进)接收和处理。相应地，所有快乐的依赖注入(inject)。
对不起所有的冗长:) 但如果有人有任何建议，我很想听听。即使(特别是)如果那个建议是“你的设计很糟糕，试试这个……”谢谢!
最佳答案
我之前曾在一个可以完成此任务的系统上工作，而且它相当简单。由于您的项目处于早期阶段，也许这对您来说可能是有用的信息。不幸的是，我不再能够访问代码，但我仍然很乐意描述它是如何工作的。
我所做的是使用通用存储库模式实现来构建我的存储库。基本存储库类型将始终由服务和 UoW 引用。为了便于讨论，我们将其称为 BaseRepository。 “T”将仅限于表示域对象的 IEntity 实现。在 BaseRepository 中，我创建了另一组用于合成的基类，例如 SqlBaseRepository、XmlBaseRepository 等。
UoW 只关心 BaseRepository 类型的东西，这是核心功能存在的地方。将表示(CRUD 的)基本 CUD，为创建、更新和删除提供等效项。它们中的每一个都会创建一个委托(delegate)并将其放入 UoW 内的队列中，同时传递有关它将是什么类型的事务的信息，以及完成它所需的适当数据。 UoW 将开始维护一个列表，其中列出了交易中需要涉及哪些存储库，但仍然不在乎它是什么类型。实际上，在这里排队就像参加交易一样。
BaseRepository 定义了一个抽象方法，称为 .ApplyChange()。一旦在 UoW 上调用了 .Commit()，它将创建一个 TransactionScope() 并开始调用列表中的委托(delegate)，将信息传回给 .ApplyChange()。 .ApplyChange() 的实际实现存在于特定的存储库库中，即 SqlRepositoryBase 等，并且也可以被实现覆盖。
至少对我来说，它变得棘手的地方是回滚。我只处理一个数据库，但有时会进行基于文件的更改。我添加了一个 .RevertChange() 方法并开始跟踪原始状态和修改后的状态，这样我基本上可以应用反向增量来回到我在文件堆栈上的位置。
我希望我可以更具体地了解实现，但是自从我现在看到代码以来已经一年多了。我可以告诉你，原始代码的基础来自这本书，.NET Domain-Driven Design with C#: Problem - Design - Solution , 蒂姆·麦卡锡。我的大部分存储库实现都是基于他的示例，而我的大部分定制都来自 UoW 及其实现。
我希望这会有所帮助! :-)
关于architecture - 具有多个数据源的工作单元？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3629500/