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

Question

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

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

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

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

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

3.2）层应该为此负责什么？

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

Answer 1

1)应用层启动一个工作单元，该工作单元转向基础设施端启动支持操作的任何类型的技术事务。承诺也是如此。

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

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

Answer 2

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

事务是应用层关注的问题。

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

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

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

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