hexagonal-architecture

原文涵盖的主题

• 六边形架构
• 适用场景
• 核心概念
• 工作原理
• 步骤1：建模用例边界
• 步骤2：首先定义出站端口
• 步骤3：使用纯编排实现用例
• 步骤4：在边缘构建适配器

六边形架构（端口与适配器）使业务逻辑独立于框架、传输层和持久化细节。核心应用依赖于抽象端口，而适配器在边缘实现这些端口。 构建需要长期可维护性和可测试性的新功能。 重构分层或框架密集型代码，其中领域逻辑与I/O关注点混杂。 为同一用例支持多种接口（HTTP、CLI、队列工作器、定时任务）。 替换基础设施（数据库、外部API、消息总线）而无需重写业务规则。 当需求涉及边界、领域驱动设计、重构紧耦合服务，或将应用逻辑与特定库解耦时，使用此技能。 领域模型：业务规则和实体/值对象。无框架导入。 用例（应用层）：编排领域行为和工作流步骤。 入站端口：描述应用能力的契约（命令/查询/用例接口）。 出站端口：应用所需依赖的契约（仓库、网关、事件发布器、时钟、UUID等）。 适配器：端口的基础设施和交付实现（HTTP控制器、数据库仓库、队列消费者、SDK封装器）。 组合根：将具体适配器绑定到用例的单一连接位置。 出站端口接口通常位于应用层（仅当抽象真正属于领域层时才位于领域层），而基础设施适配器实现它们。 依赖方向始终向内： 适配器 -> 应用/领域 应用 -> 端口接口（入站/出站契约） 领域 -> 仅领域抽象（无框架或基础设施依赖） 领域 -> 无外部依赖 定义具有清晰输入和输出DTO的单个用例。将传输细节（Express req、GraphQL context、任务负载包装器）保持在此边界之外。 将每个副作用识别为端口： 持久化（UserRepositoryPort） 外部调用（BillingGatewayPort） 横切关注点（LoggerPort、ClockPort） 端口应建模能力，而非技术。 用例类/函数通过构造函数/参数接收端口。它验证应用层不变量，协调领域规则，并返回纯数据结构。 入站适配器将协议输入转换为用例输入。 出站适配器将应用契约映射到具体API/ORM/查询构建器。 映射保持在适配器中，而非用例内部。 实例化适配器，然后将其注入用例。保持此连接集中化，以避免隐藏的服务定位器行为。 使用伪造端口对用例进行单元测试。 使用真实基础设施依赖对适配器进行集成测试。 通过入站适配器对面向用户的流程进行端到端测试。 使用以功能为先的组织方式，并带有显式边界： 在不同生态系统中使用相同的边界规则；仅语法和连接方式发生变化。 TypeScript/JavaScript 端口：application/ports/ 作为接口/类型。 用例：带有构造函数/参数注入的类/函数。 适配器：adapters/inbound/、adapters/outbound/。 组合：显式工厂/容器模块（无隐藏全局变量）。 Java 包：domain、application.port.in、application.port.out、application.usecase、adapter

这里只展示节选，请以完整原文和当前要求为准。