claude-architecture-skilllisted

# 架构决策逻辑 这份规则描述的是在面对架构设计或架构相关决策时的真实推理过程。架构决策的特殊性在于它们的影响是长期的、范围是广泛的、修改成本是高昂的。因此在架构层面的每一个决策都需要比代码层面的决策更充分的推理和更明确的权衡意识。这份文档的核心是：永远不做"最先进"的架构，只做"当前约束下最合适"的架构。 --- ## 一、架构决策的本质是权衡 ### 1.1 不存在最优架构，只存在最适合的架构 每一种架构模式都是在解决某些问题的同时引入另一些问题。微服务解决了大单体的扩展和部署问题，但引入了分布式系统的复杂性。事件驱动架构解耦了生产者和消费者，但引入了最终一致性和调试复杂性。 在做架构决策时，首先要明确：当前阶段最需要解决的问题是什么，当前阶段最难以承受的复杂性是什么。选择一种架构就是选择了它解决的问题和它引入的复杂性。 ```mermaid flowchart TD A[面临架构决策] --> B[识别当前最需要解决的问题] B --> C[识别当前最难以承受的复杂性] C --> D[列出候选架构方案] D --> E[评估每种方案解决的问题] D --> F[评估每种方案引入的复杂性] E & F --> G[与当前阶段的需要对比] G --> H[选择解决目标问题且引入可承受复杂性的方案] H --> I[明确记录选择的理由和已知的权衡] ``` ### 1.2 当前阶段的约束决定架构选择 同样的业务功能，在不同的阶段应该有不同的架构。早期产品验证阶段的最大风险是没有找到正确的产品方向，此时最重要的是快速迭代，最需要回避的是过度设计的复杂性。规模增长阶段的最大风险是系统无法支撑业务增长，此时最重要的是可扩展性，最需要回避的是单点瓶颈。成熟稳定阶段的最大风险是大规模改动引入不可控的风险，此时最重要的是稳定性，最需要回避的是不必要的重构。 ### 1.3 权衡必须被显式记录 架构决策的一个常见问题是：决策背后的权衡信息随着人员更替而丢失，导致后来的人在不理解约束的情况下做出推翻原有决策的改动，然后发现原来的问题又回来了。 每一个重要的架构决策都应该有对应的记录，说明：面临的问题是什么，考虑了哪些选项，最终选择了什么，选择的理由是什么，这个选择的已知局限是什么，以及在什么条件下这个决策应该被重新评估。 --- ## 二、分层架构的实际决策规则 ### 2.1 层的存在是为了隔离变化 分层不是为了让代码看起来有组织，而是为了在系统的某个部分发生变化时，不需要修改其他部分。每一层的边界对应一个可能发生变化的维度。 展示层隔离的变化：用户界面如何呈现，API 协议是 REST 还是 GraphQL，渠道是 Web 还是 Mobile。 业务逻辑层隔离的变化：业务规则如何运作，业务流程的顺序，权限和验证规则。 数据访问层隔离的变化：数据存储在哪里，使用什么数据库，查询如何优化。 ```mermaid flowchart TB subgraph 展示层 direction LR A1[Web 界面] A2[REST API] A3[GraphQL API] end subgraph 业务逻辑层 B1[用例\n业务流程编排] B2[领域模型\n业务规则和状态] B3[权限\n验证逻辑] end sub