SOLID 面向对象原则 (全面遵循)

• SRP (单一职责): 每个类或方法只有一个引起它变化的原因。严格杜绝上帝类 [INDEX]。
• OCP (开闭原则): 对扩展开放，对修改关闭 [INDEX]。通过接口、多态、策略模式消除硬编码的 if-else [INDEX]。
• LSP (里氏替换): 子类必须能够替换掉它们的基类，且不改变程序的正确性 [INDEX]。
• ISP (接口隔离): 客户端不应该被迫依赖它不使用的方法，接口要尽量小而精。
• DIP (依赖倒置): 高层模块不应依赖低层模块，二者都应依赖其抽象（如领域层定义仓储接口，基础设施层负责实现）。

重构与代码设计模式选型指南

AI 在编写或重构代码时，必须根据以下业务痛点，自动匹配最优的设计模式：

1. 应对分支多变/策略切换 -> 优先选择: 策略模式 (Strategy) [INDEX]、状态模式 (State)。
2. 应对长流程/多步骤流水线 -> 优先选择: 责任链模式 (Chain of Responsibility)、管道与过滤器 (Pipeline & Filter)。
3. 应对复杂的业务条件组合/校验 -> 优先选择: 规格模式 (Specification)。
4. 应对对象生命周期/复杂创建 -> 优先选择: 工厂模式 (Factory) [INDEX]、构造者模式 (Builder) [INDEX]、原型模式 (Prototype)。
5. 应对解耦/副作用/跨聚合通知 -> 优先选择: 观察者模式 (Observer / 领域事件 Domain Event)。
6. 应对第三方系统接入/防腐 -> 优先选择: 适配器模式 (Adapter)、门面模式 (Facade)。

注：AI 可以根据实际业务场景灵活选择上述以外的经典 GOF 设计模式，但必须在代码前以注释形式简述选择该模式的架构理由。

Claude Code 项目规范 (DDD 铁律与完整面向对象架构)

📌 第一部分：DDD（领域驱动设计）最高指导铁律

AI 在编写或重构任何代码时，必须无条件遵守以下 DDD 最佳实践：

1. 严格分层隔离：严格保持应用层（Application）、领域层（Domain）和基础设施层（Infrastructure）的边界。核心业务逻辑必须 100% 封闭在领域层内。
2. 领域层纯净度：领域层内严禁出现任何与数据库（如 MyBatis/JPA 注解、SQL）或外部 RPC、HTTP、MQ 强相关的技术细节。做到零基础设施技术污染。
3. 拒绝贫血模型，拥抱充血模型：严禁将实体（Entity）和值对象（Value Object）当成只有 getter/setter 的 POJO。凡是涉及实体自身的状态改变、属性计算、内部数据校验的逻辑，必须写在实体或值对象内部。Service 只能做组织和调度，不能代劳实体内部的逻辑。
4. 依赖倒置（DIP）：领域层如果需要访问数据库或外部系统，只能在领域层定义仓储（Repository）或网关（Gateway）接口。其具体技术实现必须写在基础设施层。

📌 第二部分：SOLID 面向对象原则

• SRP (单一职责原则): 每个类或方法只有一个引起它变化的原因。坚决反对上帝类，单个类的行数建议控制在 200 行以内。
• OCP (开闭原则): 对扩展开放，对修改关闭。通过接口、多态消除硬编码的 if-else 或 switch。
• LSP (里氏替换原则): 子类必须能够无缝替换掉它们的基类，不改变程序的正确性。
• ISP (接口隔离原则): 客户端不应该被迫依赖它不使用的方法，接口要尽量小而精，按业务内聚。
• DIP (依赖倒置原则): 高层模块不应依赖低层模块，二者都应依赖其抽象。

📌 第三部分：重构与设计模式选型决策树

AI 必须根据具体的业务痛点和场景，灵活且克制地选择最优的设计模式。严禁过度设计：

1. 应对分支多变、场景动态切换、多渠道差异
   • -> 优先选择：策略模式 (Strategy)、状态模式 (State)。
2. 应对长流程、前后依赖的多步骤业务流水线
   • -> 优先选择：责任链模式 (Chain of Responsibility)、管道与过滤器模式 (Pipeline & Filter)。
3. 应对复杂的业务准入条件组合、嵌套的多级校验
   • -> 优先选择：规格模式 (Specification)。
4. 应对复杂聚合根/实体的生命周期、组装、初始化逻辑
   • -> 优先选择：工厂模式 (Factory)、构造者模式 (Builder)、原型模式 (Prototype)。
5. 应对系统解耦、非核心副作用通知（如发短信、送积分）、跨聚合协同
   • -> 优先选择：观察者模式 (Observer / 对应 DDD 领域事件 Domain Event)。
6. 应对第三方系统接入、防止外部概念污染领域层
   • -> 优先选择：适配器模式 (Adapter)、门面模式 (Facade / 对应 DDD 防腐层 ACL)。

注：AI 可以根据实际业务场景灵活选择上述以外的经典 GOF 设计模式。但在创建新模式类时，必须在代码前以中文注释简述该模式的架构理由及如何服务于当前 DDD 模型。