rec*_*_ro 9 architecture interface hexagonal-architecture
我正在努力适应六边形架构，但不知道如何实现已经用不同方法实现的常见实际问题。我认为我的核心问题是了解提取到适配器和端口的责任级别。
在网络上阅读文章，使用简单的示例就可以了，例如：
我们有RepositoryInterface，可以在mysql/txt/s3/nosql存储中实现
或者
我们有NotificationSendingInterface并且有电子邮件/短信/网络推送实现
但这些都是非常精致的示例，并且只是接口/实现细节的分离。
然而在实践中，我们通常知道的接口+实现领域模型中的编码服务保证了更深入。
为了说明目的，我决定询问存储+交易对。
在十六进制架构中应该如何实现存储的事务概念？假设我们在域级别有简单的 CRUD 服务接口
StorageRepoInterface
save(...)
update(...)
delete(...)
get(...)
我们希望在使用这些方法时得到某种事务保证，例如在一个事务中删除+保存。
按照hex的构思应该如何设计和实现呢？
是否应该通过TransactionalOperation的某些外部协调接口来实现？如果是，那么一般来说，TransactionalOperation必须知道如何与StorageRepoInterface的所有实现一起实现事务保证（mb 在附加面向事务的操作接口中）
如果不是，那么域级别（十六进制内部）的StorageRepoInterface似乎应该通过其他方法提供显式事务保证？
不管怎样，它看起来并不像所说的那样“隔离和基于接口”。
有人可以指出我如何在这种情况下正确改变心态或在哪里阅读？
提前致谢。
cho*_*o70 11
在 Hex Arch 中，驱动程序端口是应用程序的 API，即用例边界。用例是事务性的。因此，您必须控制驱动程序端口方法的事务性。您将每个方法都包含在事务中。
如果您使用 Spring，您可以使用声明式事务（@Transactional 注释）。
另一种方法是在方法执行之前显式打开数据库事务，并在方法执行之后关闭（提交/回滚）它。
应用事务性的一个有用模式是命令总线，用装饰器包装它，将命令封装在事务中。
事务是基础设施，因此您应该有一个驱动端口和一个实现该端口的适配器。
该实现必须使用与持久性适配器（存储库）使用的相同的数据库上下文（实体管理器）。
Vaughn Vernon 在他的书“Implementing DDD”的“Managing transactions”部分（第 432-437 页）讨论了这个主题。