我想在我的应用程序中使用ASP.Net WebApi实现域单元模式的域驱动设计。域驱动的设计 - 数据库事务管理
1）我应该在哪里开始/提交交易（API控制器，应用层/服务，DAL，域层/服务）？
2）什么是最好的方式来管理复杂的应用程序中的交易与许多商业规则（AOP，显式调用或其他方式）？
3）在更大的事务中重用一段代码与事务的最佳方式是什么？ i.g.我有独立的用例 - 关闭发票 - 其中已包含交易。此外，此代码包含一些非域名代码，如日志记录，统计计数等。 我想在更复杂的用例中重复使用此代码 - 支付发票，扣除佣金和关闭发票。
3.1）如何处理内部事务问题（流行的数据库不支持它）？
3.2）层应该负责什么？
我知道答案可能取决于一个特定的项目。但是，考虑任何可行的实际项目技术将是很好的
1）应用层启动一个工作单元，它转向基础设施端以启动哪种技术交易支持该操作。相同的承诺。
2）与小型应用程序完全相同。无论业务规则的数量如何，交易通常都发生在总量周围。对于长时间运行，非常复杂的多部分用例，您可以使用Sagas。
3）一些选项，按优先顺序排列：1.只需重用域并订阅域事件来管理诸如统计或日志等事情。 2.在应用层中，在较大和较小的用例之间共享代码，但在事务/ UoW代码之间共享代码。将它全部保存在单个事务中。 3.使用流程管理器将呼叫协调为较小的用例，作为较大用例（Saga）的一部分。
1）我应该在哪里开始/提交事务（API控制器， 应用程序层/服务，DAL，域层/服务）？
交易是应用层的一个问题。
2）有什么用了很多bussines规则（AOP，显式调用或其他某种方式）来管理复杂的应用 交易的最佳方式？
它有点依赖于您正在使用的持久性/ ORM框架。实体框架和NHibernate支持更改跟踪可以使工作单元（提交和回滚）更容易。为确保在同一事务中进行更改，存储库必须使用相同的工作单元实例（例如，的DbContext，会话）
3）什么是重用与交易一段代码在 更多更大的交易的最佳方式？胃内我有独立的使用案例 - 关闭 发票 - 其中已包含交易。此代码 包含一些非域名代码，如日志记录，统计计数和 等。我想在更复杂的用例中重复使用此代码 - 支付 发票，扣除佣金并关闭发票。
日志记录是贯穿始终的问题，不应该影响用例。这些依赖关系是通过构造函数或属性注入的。像统一一样使用控制容器的反转。
你需要首先学习DDD。此时您正在使用DDD名称进行CRUD。 – MikeSW
@MikeSW，我读过Eric Evans的DDD，但我仍然不明白如何在域驱动设计的应用程序中正确管理数据库事务。 – Albert
这是因为DDD和DB事务是非常不同的事情。开始阅读Vaughn Vernon的书或我的[DDD教程]（http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-1）以了解DDD的真正含义。我花了大约7年的时间才真正了解DDD :)但今天有更多的资源比以往任何时候都多。祝你好运！ – MikeSW