用途
Oracle Architect 是一个架构设计技能，用于在功能设计、领域建模、任务拆解和理解组件时提供结构化的架构方法。它把领域驱动设计（DDD）、六边形架构与函数式核心模式整合为一套可执行的决策框架。
核心概念与术语
技能强调使用精确、一致的词汇：
- 模块（Module）：任何具有接口和实现的东西，如函数、类、包、层。Router、Service、Entity、Repository 都是模块。
- 接口（Interface）：调用者使用模块所需知道的一切，包括类型、不变量、错误模式、顺序、配置，而不仅是类型签名。
- 接缝（Seam）：模块接口所在之处，是可以在不就地修改的情况下改变行为的位置。函数式核心与副作用边缘的边界是主要接缝。
- 深度（Depth）：接口处的杠杆。大量行为位于小接口之后即为深模块；接口几乎与实现一样复杂即为浅模块。
- 适配器（Adapter）：在接缝处满足接口的具体实现。Postgres 仓储是一个适配器，用于测试的内存假实现是同一接缝上的另一个适配器。
- 杠杆（Leverage）：调用者从深度中获得的东西——每学习一单位接口获得更多能力。
- 局部性（Locality）：维护者从深度中获得的东西——变更、缺陷和知识集中在一处。
关键原则
- 删除测试：设想删除该模块。如果复杂度消失，它只是直通；如果复杂度在 N 个调用者处重新出现，它就在发挥价值。
- 接口即测试面：调用者和测试跨越同一接缝。如果想测试接口之外，模块形状可能不对。
- 适配器规则：一个适配器是假设接缝，两个适配器才是真实接缝。除非确实有东西在接缝上变化，否则不要引入接缝。
架构模型
系统分为两部分：
- 副作用边缘（IO）：Router 负责请求解析，Consumer 负责事件处理，Client 负责外部 API，Producer 负责事件发布，Repository 负责数据持久化。
- 函数式核心（纯）：Service 负责编排，Entity 负责领域规则、校验与转换。
关键原则：业务逻辑位于函数式核心（Service + Entity），IO 操作位于副作用边缘。核心定义接口，边缘实现接口（依赖倒置）。
架构决策评估
在创建新模块前运行以下检查：
- 删除测试：判断是否应提取新的 Service、Repository 或工具类。浅模块示例是每个字段一个方法的 OrderFormatterService，删除它只是把 6 行移入 Router；深模块示例是包含 validate → reserve → save → publish 的 OrderService，删除它会在 N 个处理器中复制编排逻辑。
- 接口即测试面：Entity 的单元测试测试公共接口（validate、transform）；Service 的单元测试通过接缝并使用桩仓储；Repository 的集成测试测试真实适配器。如果发现自己在测试“内部”方法，模块需要重新设计。
- 适配器规则：只有一个适配器时接口只增加间接性而无价值；存在两个适配器（如生产用 PostgresOrderRepository 与测试用 InMemoryOrderRepository）时接缝才有价值。
- 深度检查：优先深模块。经验法则：模块接口应隐藏至少 3 倍于其暴露的复杂度。
函数式核心
Service 层
职责：编排业务操作，协调实体与仓储。特征：纯函数，接收数据返回结果；无 IO 操作（数据库、HTTP、文件系统）；通过接口调用仓储（依赖注入）；将实体操作组合为工作流；返回成功/错误结果。示例中 createOrder 先通过实体校验，再检查业务规则、预留库存、持久化并返回结果。
Entity 层
职责：领域模型、校验、业务规则、数据转换。特征：带行为的纯数据结构；所有校验逻辑；数据转换（fromRequest、toRecord、toResponse）；业务规则与不变量；无 IO、无框架依赖。示例中 Order 包含 fromRequest、toRecord、validate、canCancel 等方法。
副作用边缘
Router
职责：HTTP 请求处理、解析、响应格式化。特征：将 HTTP 请求解析为领域类型；用解析后的数据调用服务层；将服务结果格式化为 HTTP 响应；处理 HTTP 特定关注点（状态码、头）；无业务逻辑。
Repository
职责：数据持久化与检索。特征：实现服务使用的数据访问接口；在领域实体与数据库记录之间转换；处理数据库查询与事务；无业务逻辑或校验。
组件矩阵
提供关注点、组件、层与可测试性的快速参考：领域模型、校验、业务规则、数据转换属于 Entity/Core，用纯单元测试；编排属于 Service/Core，用桩仓储单元测试；HTTP 解析属于 Router/Edge，数据访问属于 Repository/Edge，外部 API 属于 Client/Edge，事件处理属于 Consumer/Edge，事件发布属于 Producer/Edge，均用集成测试。
任务拆解
采用自底向上的依赖排序：1. Entity（领域模型、校验、转换）；2. Repository（数据访问接口与实现）；3. Service（业务逻辑编排）；4. Router（HTTP 端点）。理由：每层依赖其下层，没有实体无法实现服务，没有服务无法实现路由。任务粒度上，每层一个任务；复杂功能可进一步拆分，如 Entity 拆为 Order、OrderItem、OrderStatus，Repository 拆为 OrderRepository、InventoryRepository 等。
架构到测试的流程
架构决策指导测试策略：组件职责决定测什么，层边界决定在哪测，纯与副作用决定单元还是集成，实体转换对应属性测试，服务编排对应桩驱动测试。测试技能利用架构结构确定：核心做单元测试、边缘做集成测试；测试边界位置；什么打桩、什么测真实；哪些测试用例验证业务规则。
参考资料
- references/ddd-patterns.md：聚合、值对象、领域事件、限界上下文、组合模式、接缝放置。
- references/data-modeling.md：实体设计原则、模式模式、访问模式优化、数据转换。
- references/api-design.md：REST 约定、请求/响应契约、错误处理、版本化模式。
- references/interface-design.md：设计模块接口、“Design It Twice”模式、深度启发式、依赖类别、反模式。
限制
资料未提供该技能的具体安装方式、运行环境、支持平台、收费模式或价格信息，这些内容暂未提供。