使用HTTP方法语义：GET用于获取资源，POST用于创建资源，PUT用于更新资源，DELETE用于删除资源

URL中包含操作动词，如 /api/getUser、/api/deleteOrder

使用复数名词表示资源集合，如 /users、/orders

在URL中传递敏感参数，如 /api/users?password=xxx

使用HTTP状态码表示响应结果，如200表示成功，404表示资源不存在

所有API都返回200状态码，在响应体中用自定义字段表示错误

API版本号放在URL路径中，如 /api/v1/users

API版本号放在请求头中，如 Accept: application/vnd.api+json;version=1

URL路径版本化简单直观，便于客户端理解和使用

请求头版本化更符合REST原则，URL保持简洁

版本升级时应该立即废弃旧版本，强制所有客户端迁移

应提供版本过渡期，给予客户端足够的迁移时间

不同版本API可以共存，使用路由分发处理

向后兼容的改动（如添加可选字段）不需要升级版本号

创建资源成功返回201 Created

删除资源成功返回204 No Content

客户端请求参数错误返回400 Bad Request

客户端未提供认证信息返回401 Unauthorized

客户端已认证但无权限访问返回403 Forbidden

请求的资源不存在返回500 Internal Server Error

客户端请求条件不满足返回409 Conflict

请求超时返回408 Request Timeout

使用Basic Auth将用户名密码放在请求头中

JWT Token应该设置合理的过期时间，并使用强密钥签名

API Key应该硬编码在客户端代码中便于调用

敏感API不需要任何认证，只需验证请求来源IP

重构应该在添加新功能之前进行，使代码结构更清晰

重构应该在修复Bug时进行，使代码更容易定位问题

重构应该一次性完成所有改动，避免多次提交

重构必须保持代码功能不变，外部行为不能改变

重构时应该同时修改代码结构和功能

重构需要测试保障，每个重构步骤都应该可验证

重构时机包括：代码难以理解、重复代码过多、方法过长

重构应该遵循"小步前进"原则，每次只做一个小改动

提取方法（Extract Method）：将一段代码提取为独立方法

内联方法（Inline Method）：将方法调用替换为方法体内容

提取变量（Extract Variable）：将复杂表达式结果存入临时变量

提升方法（Pull Up Method）：将子类方法移动到父类

降低方法（Push Down Method）：将父类方法移动到子类

重命名方法（Rename Method）：使方法名更清晰表达意图

封装字段（Encapsulate Field）：将公开字段改为私有并添加getter/setter

删除重复代码（Remove Duplicate Code）：直接删除所有相似代码

重复代码（Duplicated Code）：相同代码出现在多处

过长方法（Long Method）：方法超过10行就需要重构

过大类（Large Class）：类承担太多职责

过长参数列表（Long Parameter List）：方法参数过多

发散式变化（Divergent Change）：一个类因多种原因被修改

霰弹式修改（Shotgun Surgery）：一个改动需要修改多个类

依恋情结（Feature Envy）：方法过多使用其他类数据

数据泥团（Data Clumps）：多个数据总是一起出现

重命名速度更快，节省开发时间

自动更新所有引用，避免遗漏导致代码错误

可以同时修改多个文件的注释内容

自动生成重命名操作的Git提交记录

直接将整个单体应用拆分为几十个微服务

采用渐进式拆分，优先拆分边界清晰的模块

先建立微服务基础设施（服务发现、配置中心、消息队列）

拆分前确保单体应用有清晰的模块边界和接口定义

每次拆分一个服务后立即上线，无需验证

使用绞杀者模式（Strangler Pattern）逐步替换功能

数据库应该先拆分，再拆分应用服务

保持新旧系统并行运行，逐步切换流量

每个微服务应该围绕业务能力边界划分

微服务越小越好，一个服务只做一件事

服务边界应该与团队组织边界对应（康威定律）

高内聚低耦合是确定边界的核心原则

共享数据库表的服务应该合并为一个服务

服务间调用次数越少越好，减少通信开销

一个服务可以包含多个相关的业务实体

服务拆分后应该能独立开发、测试、部署

先保持共享数据库，应用服务拆分后再拆分数据库

使用数据同步机制保持新旧数据库数据一致

使用分布式事务保证跨服务数据一致性

最终一致性比强一致性更适合微服务场景

使用事件溯源模式解耦服务间数据依赖

数据迁移期间应该禁止用户操作

使用Saga模式处理跨服务长事务

读取数据时可以同时查询新旧数据库验证一致性

使用特性开关控制新旧系统切换，可随时回滚

架构演进完成后进行一次性全面测试

一次性切换所有用户到新系统

新系统上线后立即删除旧系统代码

单一职责原则(SRP)：一个类只负责一个职责

开闭原则(OCP)：对扩展开放，对修改关闭

里氏替换原则(LSP)：子类可以替换父类使用

接口隔离原则(ISP)：使用多个专门接口而非通用接口

依赖倒置原则(DIP)：高层模块依赖抽象而非具体实现

将所有方法都放在一个类中，便于统一管理

使用继承重写父类方法时，改变方法的预期行为

高层模块直接依赖底层模块的具体实现类

将用户管理类拆分为用户信息类、用户持久化类、用户验证类

将日志记录功能从业务类中提取为独立的日志服务类

一个类既处理业务逻辑又负责数据库连接管理

将报表生成逻辑从订单处理类中分离到报表生成类

将权限检查逻辑从控制器类中分离到权限过滤器类

一个服务类同时处理API请求、数据验证、数据库操作

将缓存管理功能提取为独立的缓存服务类

使用策略模式，通过添加新策略类来扩展功能

使用装饰器模式，在不修改原类的情况下添加新功能

使用继承重写父类方法来添加新功能

修改已有类的源代码来添加新的业务分支

使用模板方法模式，子类实现具体步骤

使用工厂模式，通过添加新工厂类支持新类型

在已有方法中添加if-else分支处理新情况

使用观察者模式，添加新观察者扩展行为

子类重写父类方法，但保持方法的预期行为不变

子类在父类方法基础上添加了额外的可选功能

子类重写父类方法时抛出了父类方法不会抛出的异常

子类实现父类的抽象方法，提供具体的实现逻辑

单例模式：使用__new__方法控制实例创建，确保只有一个实例

单例模式：使用模块级别的变量实现单例，Python模块天然单例

工厂模式：使用工厂类创建对象，隐藏具体创建逻辑

工厂模式：使用__init_subclass__实现自动注册工厂

策略模式：使用函数而非类实现策略，利用Python函数是一等对象

策略模式：使用字典映射策略名称到策略函数

观察者模式：使用列表管理观察者，通过循环调用通知方法

所有设计模式都必须严格按照类结构实现

使用模块级变量实现单例是最简单且推荐的方式

使用装饰器可以实现单例，且代码更简洁

使用__new__方法可以控制实例创建过程

单例模式在Python中必须使用类来实现

元类(metaclass)可以用来实现单例模式

使用类属性存储实例，配合__new__实现单例

Python的模块天然是单例，导入多次返回同一模块对象

线程安全是单例实现需要考虑的问题

需要根据配置动态创建不同类型的对象时使用工厂模式

对象创建逻辑复杂，需要隐藏创建细节时使用工厂模式

需要在运行时切换算法实现时使用策略模式

一个操作有多种实现方式，需要灵活选择时使用策略模式

创建对象时需要参数验证和预处理时使用工厂模式

需要将算法的使用者和算法实现解耦时使用策略模式

简单的对象创建直接调用构造函数，不需要工厂模式

工厂模式可以配合依赖注入容器实现自动创建

直接调用观察者的具体方法名，如observer.log_event()

调用观察者的统一接口方法，如observer.on_event(event)

观察者主动轮询主题获取状态变化

主题将所有观察者转换为同一类型后统一调用

依赖注入将对象的创建和绑定责任从类本身移交给外部

依赖注入提高了代码的可测试性，便于使用Mock对象进行测试

构造函数注入是最推荐的依赖注入方式

Setter方法注入适用于可选依赖或需要运行时更换的场景

接口注入要求类实现特定接口来接收依赖

依赖注入容器自动管理对象的生命周期和依赖关系

依赖注入会导致代码过度复杂，简单场景不应使用

使用依赖注入后，类不再依赖具体的实现类，只依赖抽象

构造函数注入适合必需依赖，对象创建后即可使用

Setter方法注入适合可选依赖，可以在运行时更换

接口注入需要类实现特定的注入接口方法

构造函数注入的依赖在对象生命周期内不可变

Setter方法注入可能导致对象处于不完整状态

所有依赖都应该使用构造函数注入，Setter注入不推荐

接口注入是最灵活的方式，应该优先使用

混合使用多种注入方式可以根据依赖特性选择最佳方式

自动解析依赖关系并创建对象

管理对象的生命周期（Singleton、Scoped、Transient）

配置抽象接口到具体实现的绑定关系

处理循环依赖问题

支持装饰器标记需要注入的依赖

自动注入Mock对象用于测试

支持条件化依赖注册

提供依赖替换和覆盖机制

可以避免编写测试代码，依赖注入自动测试

可以使用Mock对象替换真实依赖，实现测试隔离

可以减少测试运行时间，依赖注入优化性能

可以自动生成测试用例，依赖注入分析代码

领域(Domain)：业务问题空间和知识领域

限界上下文(Bounded Context)：明确的业务边界和模型边界

聚合(Aggregate)：一组相关对象的集合，作为数据修改的单元

实体(Entity)：有唯一标识的对象，身份不变属性可变

值对象(Value Object)：没有唯一标识，通过属性值定义的对象

领域服务(Domain Service)：不属于任何实体或值对象的领域操作

应用服务(Application Service)：协调领域对象完成业务用例

仓储(Repository)：管理聚合的持久化和检索

聚合根是聚合的唯一入口，外部只能通过聚合根访问聚合内对象

聚合应该尽量小，只包含必要的对象

聰合之间通过ID引用，不直接持有对方的对象引用

聚合保证内部一致性，边界内的事务完整性由聚合根负责

聚合根应该包含所有业务规则验证逻辑

一个聚合可以包含多个聚合根

聚合内对象可以被外部直接修改

仓储只管理聚合根，不直接访问聚合内对象

实体有唯一标识，值对象没有唯一标识

实体属性可以变化，值对象应该不可变

实体通过标识判断相等，值对象通过所有属性判断相等

实体有生命周期可追踪，值对象可以被随意替换

值对象应该尽量使用，实体只在必要时使用

值对象的计算操作应该返回新的值对象

实体的标识一旦创建就不能改变

值对象可以包含实体作为属性

执行复杂的数据库查询和报表生成

管理聚合的持久化和检索，模拟内存中的集合

实现业务逻辑和业务规则验证

处理跨聚合的事务协调和一致性

使用FastAPI或Flask构建轻量级REST API服务

使用gRPC进行高性能的服务间通信

使用消息队列（如RabbitMQ、Kafka）实现异步通信

使用服务发现机制（如Consul、Nacos）动态发现服务

每个微服务使用独立的数据库，不共享数据库

使用API网关统一入口，处理认证、限流、路由

使用分布式追踪系统（如Jaeger、Zipkin）监控调用链

使用熔断器（如Circuit Breaker）防止故障蔓延

同步通信（REST/gRPC）适合需要实时响应的场景

异步通信（消息队列）适合耗时操作和解耦场景

REST API简单易用，适合公开API和跨语言调用

gRPC性能更高，适合内部服务间高频调用

事件驱动架构可以实现服务间的松耦合

同步调用链过长会导致延迟累积和超时问题

所有服务间通信都应该使用同步方式确保实时性

混合使用同步和异步通信可以平衡实时性和解耦性

每个微服务拥有独立的数据库，实现数据隔离

需要其他服务数据时，通过API调用获取

使用事件驱动模式在服务间同步数据副本

跨服务事务使用Saga模式保证最终一致性

使用分布式事务（XA）保证强一致性

为避免跨服务查询，可以在一个服务中复制其他服务数据

复制数据时，要明确区分数据所有权和只读副本

使用CQRS模式分离读写操作