领域驱动设计——数据库事务管理答案

【问题标题】：Domain driven design - database transaction management领域驱动设计——数据库事务管理
【发布时间】：2017-08-11 21:07:09
【问题描述】：

我正在尝试使用 ASP.Net WebApi 在我的应用中实现具有模式单元的领域驱动设计。

1) 我应该在哪里开始/提交事务（API 控制器、应用层/服务、DAL、域层/服务）？

2) 在具有大量业务规则的复杂应用程序中管理事务的最佳方式是什么（AOP、显式调用或其他方式）？

3) 在更大的事务中重用一段代码与事务的最佳方法是什么？ 例如我有独立的用例 - 关闭发票 - 其中已经包含交易。此代码还包含一些非域代码，如日志记录、统计计数等。我想在更复杂的用例中重用这段代码 - 支付发票、扣除佣金和关闭发票。

3.1)如何处理内部事务问题（流行的数据库不支持）？

3.2) 层应该对此负责吗？

我知道答案可能取决于特定项目。但是考虑任何在实际项目中可行的技术会很棒

【问题讨论】：

你需要先真正学习 DDD。此时，您正在使用 DDD 名称进行 CRUD。
@MikeSW，我读过 Eric Evans 的 DDD，但我仍然不明白如何使用域驱动设计正确管理应用程序中的数据库事务。
那是因为 DDD 和 DB 事务是非常不同的东西。开始阅读 Vaughn Vernon 的书或我的 DDD tutorials 以了解 DDD 的真正含义。我花了大约 7 年的时间才真正了解 DDD :) 但今天的资源比以往任何时候都多。祝你好运！

【解决方案1】：

1) 我应该在哪里开始/提交事务（API 控制器，应用层/服务、DAL、域层/服务）？

事务是应用层的关注点。

2) 在复杂应用程序中管理事务的最佳方式是什么有很多业务规则（AOP、显式调用或其他）？

这有点取决于您使用的持久性/ORM 框架。实体框架和 NHibernate 支持更改跟踪可以使您的工作单元（提交和回滚）变得容易。为确保在同一事务中进行更改，存储库必须使用相同的工作单元实例（例如 DbContext、会话）

3) 在事务中重用一段代码的最佳方法是什么更大的交易？例如我有独立的用例 - 关闭发票 - 已经包含交易。还有这段代码包含一些非域代码，如日志记录、统计计数和等等，我想在更复杂的用例中重用这段代码 - 付费发票、佣金扣除和结算发票。

日志是横切关注点，不应影响用例。这些依赖项是通过构造函数或属性注入的。使用 Unity 等控制容器的反转。

【讨论】：

【解决方案2】：

1) 应用程序层启动一个工作单元，该工作单元转向基础架构端以启动支持该操作的任何类型的技术事务。提交也是一样。

2) 与小型应用程序完全相同。无论业务规则的数量如何，事务通常都围绕聚合进行。对于运行时间非常长、非常复杂的多部分用例，您可以使用 Sagas。

3) 一些选项，按优先顺序排列： 1. 只需重用域并订阅域事件来管理诸如统计信息或日志记录之类的事情。 2. 在应用层，在更大和更小的用例之间共享代码，但不共享事务/UoW 代码。将其全部保存在单个事务中。 3. 使用流程管理器来协调对较小用例的调用，作为较大用例 (Saga) 的一部分。

【讨论】：