六边形体系结构和交易概念

Question

我正在尝试习惯六边形架构，但不知道如何实现常见的实际问题，这些问题已经通过不同的方法实现。我认为我的核心问题是了解提取到适配器和端口的责任级别。

在网络上阅读文章是可以的，例如：

我们有 RepositoryInterface 可以在 mysql/txt/s3/nosql 存储

或

我们有 NotificationSendingInterface 和电子邮件/短信/网络推送实现

但这些都是非常精炼的示例，只是接口/实现细节分离。

然而在实践中，域模型中的编码服务我们通常对接口+实现的保证更加深入。

为了举例说明，我决定询问存储+事务对。

存储的事务概念应该如何在十六进制架构中实现？ 假设我们在域级别有简单的 crud 服务接口

StorageRepoInterface
   save(...)
   update(...)
   delete(...)
   get(...)

在使用这些方法时，我们需要某种交易保证，例如删除+保存在一个事务中。

按照十六进制的概念应该如何设计和实现？

是否应该用TransactionalOperation的一些外部协调接口来实现？如果是，那么一般来说，TransactionalOperation 必须知道如何实现与 StorageRepoInterface 的所有实现一起使用的事务保证（mb 在额外的面向事务的操作接口中）

如果不是，那么似乎应该有来自域级别（十六进制内部）StorageRepoInterface 的显式事务保证以及其他方法？

无论哪种方式，它都不像所说的那样“基于隔离和接口”。

有人能告诉我如何在这种情况下正确改变思维方式或在哪里阅读吗？

提前致谢。

Answer 1

在 Hex Arch 中，驱动程序端口是应用程序的 API，即用例边界。用例是事务性的。因此，您必须控制驱动程序端口方法的事务性。您将每个方法都包含在事务中。

如果你使用 Spring，你可以使用声明式事务（@Transactional 注释）。

另一种方法是在方法执行之前显式打开一个数据库事务，并在方法之后关闭（提交/回滚）它。

应用事务性的一个有用模式是命令总线，用装饰器包装它，将命令包含在事务中。

事务是基础设施，因此您应该有一个驱动端口和一个实现该端口的适配器。

实现必须使用与持久性适配器（存储库）相同的数据库上下文（实体管理器）。

Vaughn Vernon 在他的书“实施 DDD”的“管理事务”部分（第 432-437 页）谈到了这个话题。