六边形架构中TransactionService依赖AccountService是否属于紧耦合？

当前设计是否合理 #

当前设计不存在原则性错误，属于符合分层架构逻辑的常规实现。
AccountService的定位是账户领域的原子能力服务，本身就不需要强制被Controller层直接调用：把账户查询、余额校验等和账户属性强相关的逻辑收敛在AccountService内部，避免TransactionService直接操作AccountRepository，反而符合单一职责原则，后续如果要修改账户余额校验规则，只需要调整AccountService内部逻辑即可，不需要改动TransactionService的代码。
唯一的潜在问题是如果TransactionService直接依赖AccountService的具体实现类，会提升单元测试的mock成本，同时后续替换账户服务实现的灵活性较低。

更优雅的优化方案 #

可以从以下几个方向做优化：

• 做依赖倒置抽象：提取AccountAbilityPort接口，仅声明TransactionService需要的queryAccountById、isBalanceSufficient两个方法，让AccountService实现该接口，TransactionService依赖接口而非具体实现类，降低耦合的同时也方便单测时mock接口实现。
• 领域逻辑下沉：如果采用DDD架构，可以把余额校验、金额扣减的逻辑放到Account实体的内部方法中，比如新增boolean tryDeduct(BigDecimal amount)方法，直接在实体内部完成余额判断和扣减，避免业务逻辑泄露到服务层。
• 校验逻辑统一封装：如果后续会新增多类交易校验规则（比如风控校验、交易限额校验），可以抽象统一的TransactionValidator校验器组件，把所有校验逻辑收敛到统一入口，TransactionService创建交易时直接调用校验器即可，避免校验逻辑散落在业务代码中。

六边形架构的服务依赖耦合问题 #

服务之间互相依赖本身不代表紧耦合，是否符合六边形架构的要求核心看依赖的形态：
六边形架构的核心原则是核心业务逻辑不依赖外部具体实现，所有外部交互都通过抽象端口完成。如果两个服务都是核心域的内部服务，且依赖的是对方的抽象接口而非具体实现，属于正常的域内能力协作，完全符合架构要求；只有当你直接依赖外部服务的具体实现、甚至绕开服务直接操作对方的存储资源时，才属于违反架构原则的紧耦合设计。

内容的提问来源于stack exchange，提问作者Sheen