系统架构设计专家助手技能，提供完整的架构方法论指导，涵盖分层架构、微服务架构、事件驱动架构、CQRS、六边形架构等多种架构风格。包含架构决策记录ADR模板、微服务拆分原则、服务治理策略，帮助设计师构建可扩展、可维护、高可用的系统。

系统架构设计技能：分层微服务事件驱动的架构方法论

【适用场景】

Step 1：系统设计初期选型

当需要为一个新系统选择架构风格时，根据业务规模、团队能力、技术债务等因素，选择最适合的架构模式。例如：初创公司选择单体分层快速起步，中型团队选择微服务实现独立部署，大型平台选择事件驱动应对高并发。

Step 2：微服务拆分与边界定义

当系统需要从单体拆分为微服务时，按照业务能力边界进行拆分，明确服务间通信方式、数据一致性策略、服务治理方案。

Step 3：架构决策记录

当面临技术选型决策时（如数据库选型、缓存策略、消息队列选型），使用ADR格式记录决策背景、选项对比、决策理由和后果。

Step 4：非功能性设计

在架构设计时同步考虑性能、可用性、安全性、可观测性等非功能性需求，避免上线后才发现架构瓶颈。

【操作步骤】

第一步：确定架构风格

根据系统规模、团队能力、业务需求选择架构风格： - 单体分层：小型项目、初创期，简单快速 - 微服务：大型系统、独立团队，独立部署技术异构 - 事件驱动：实时处理、解耦场景，松耦合可扩展 - CQRS：读写差异大的系统，读写分离优化 - 六边形架构：领域驱动的系统，领域纯净可测试

第二步：分层架构设计

采用标准四层架构： - 展示层：控制器/路由接收请求，参数校验 - 应用层：应用服务编排业务流程，DTO跨层数据传输 - 领域层：实体、值对象、聚合根、领域服务、领域事件，核心业务规则零外部依赖 - 基础设施层：仓储实现、外部服务集成、消息发送

依赖方向规则：展示层→应用层→领域层←基础设施层，领域层是最纯净的核心。

第三步：微服务拆分（按需）

按业务能力拆分，而非技术层。单个服务由6-8人团队独立维护，服务间松耦合，服务内高内聚。通信方式根据场景选择： - 同步REST：简单查询、需要即时响应 - 同步gRPC：高性能内部调用 - 异步消息：解耦、削峰填谷 - 事件通知：状态变更广播，最终一致性

第四步：数据一致性策略

根据业务场景选择一致性模式： - Saga编排：长事务、多服务，每步有补偿操作 - Saga协调：复杂流程，中央协调器驱动 - CQRS：读写分离，最终一致性 - 事件溯源：事件即数据，支持重放

第五步：服务治理

配置完整的服务治理体系：服务注册发现、配置中心动态刷新、网关统一入口限流鉴权、熔断降级防止级联故障、链路追踪全链路可观测。

【代码模板】

架构决策记录ADR模板： ```

ADR-{编号}: {决策标题}

背景

- 当前面临的问题或需求 - 约束条件

选项

1. 选项A：描述 + 优点 + 缺点 2. 选项B：描述 + 优点 + 缺点

决策

选择 {选项X}

理由

- 为什么选择该选项 - 关键权衡

后果

- 正面影响 - 负面影响和缓解措施 ```

分层架构依赖关系： ``` 展示层 → 应用层 → 领域层 ← 基础设施层

领域层不依赖任何外层，是最纯净的基础设施层实现领域层定义的接口（依赖倒置）禁止跨层直接调用 ```

微服务拆分检查清单： - [ ] 按业务能力拆分，而非技术层 - [ ] 单个服务可由6-8人团队独立维护 - [ ] 服务间松耦合，服务内高内聚 - [ ] 每个服务拥有独立的数据存储 - [ ] 拆分粒度先粗后细，按需拆分 ```

【复盘要点】

1. 架构反模式：大泥球（无分层无边界）、分布式单体（微服务拆分但共享数据库）、黄金锤（强行用一种技术解决所有问题）、过早优化（未验证瓶颈就做复杂优化）、God Object（一个服务承担过多职责）。

2. 代码质量强制：领域层零外部依赖、接口定义在领域层、禁止跨层直接调用、配置外部化、服务无状态、每个决策有ADR。

3. 架构评审清单：是否满足业务需求无过度设计、是否符合架构原则、是否考虑非功能性需求、是否有ADR、是否考虑故障场景、是否具备可观测性、是否有演进路径。

来源：dkbnull/hello-skill (GitHub) | https://raw.githubusercontent.com/dkbnull/hello-skill/main/common/skills/architecture/SKILL.md