# 055
面向对象设计的五大原则，打造可维护、灵活的代码
# 057
23种经典的创建型、结构型、行为型设计模式
# 058
编写可读、简洁、表达力强且最小化意外的代码
# 059
领域驱动设计的实现构建块：实体、值对象、聚合
# 060
通过端口与适配器将核心逻辑与外部关注点隔离
# 063
REST API 从 RPC 到超媒体的四级成熟度模型
# 064
将状态持久化为不可变的追加事件序列而非当前快照
# 065
构建高效大模型提示词的结构化技术模式集合
# 066
使大模型代理能在推理循环中调用外部工具
# 067
带前缀的代码评审注释，提升清晰度与可操作性
# 068
使用主版本.次版本.补丁版本语义对API和库进行版本控制
# 069
通过共享的消费者-提供者契约验证服务间交互的正确性
# 070
通过包装遗留代码模块并将调用重定向到新实现来渐进式替换旧代码
# 071
使用条件分支控制代码执行路径，无需重新部署即可启用或禁用功能
# 072
优先使用不可变数据结构以消除共享可变状态，提高安全性、并发性和可推理性
# 073
通过提供实现预期接口的默认行为对象（无操作或安全默认值）来消除空值检查
# 074
利用类型系统编码业务规则和约束，使无效状态在编译时不可表示
# 075
将可互换的算法封装在统一接口后，使算法可独立于使用方变化
# 076
当对象状态发生变化时自动通知所有依赖方
# 077
将对象的创建委托给子类决定，使父类无需依赖具体产品类
# 078
在不指定具体类的情况下创建一系列相关或相互依赖的对象
# 079
动态地为对象添加额外职责，是子类化扩展功能的灵活替代方案
# 080
将一个类的接口转换为客户期望的另一个接口，使原本不兼容的类可以协作
# 081
确保一个类只有一个实例，并提供一个访问它的全局入口点
# 082
将请求封装为对象，从而支持撤销、排队或日志记录等操作
# 083
在基类中定义算法骨架，允许子类覆盖特定步骤而不改变算法整体结构
# 084
允许对象在内部状态改变时自动改变其行为，使其看起来像改变了类
# 085
使用类集合接口在领域模型与数据映射层之间进行中介，解耦业务逻辑与数据访问
# 086
在业务事务期间跟踪对象变更，并将其作为单一原子批次提交到数据库
# 087
在内存对象与数据库之间传输数据，同时保持两者相互独立，领域对象对持久化完全无知
# 088
使用流式 API 逐步构建复杂对象，将构建过程与对象表示分离，支持多种表示形式
# 089
将处理步骤链接成管道，每个步骤可检查、转换请求或短路请求的流动，实现横切关注点的解耦
# 090
通过在旧实现旁边逐步构建新实现来替换遗留代码模块，直到遗留代码可以安全移除
# 091
按功能而非技术层次组织代码，将一个功能的所有代码——从HTTP处理器到数据库查询——组合在单一的内聚切片中
# 092
将业务规则封装为可组合、可复用的对象，通过布尔逻辑组合来表达复杂的领域谓词
# 093
GoF 结构型模式，通过共享可外化状态的细粒度对象来最小化内存使用，使大量相似对象得以高效表示。
# 094
在进程或层之间传递数据的简单对象，不包含任何业务逻辑——其唯一目的是通过将数据打包成单一传输单元来减少方法调用次数
# 095
系统中的每一条知识都必须有唯一、明确、权威性的表述。当你在两个地方写相同的代码时，就应该将其提取为唯一的权威来源。
# 096
大多数系统保持简单比过度设计更有效。复杂性是可靠性的敌人。设计最简单可能工作的方案，抗拒过度巧妙的诱惑。
# 097
只在真正需要时才实现功能，不要因为预见未来可能需要就提前实现。过早泛化与过早优化同样有害。
# 098
为了实现代码复用和多态，应优先采用对象组合而非类继承。继承在父子类之间建立紧耦合；组合则将行为从可互换的部件中组装，使系…
# 099
模块不应该了解其操作对象的内部运作。一个对象只应调用：它自身、它的参数、它创建的对象以及它直接的组件对象的方法——而不是…
# 100
将数据库行封装并在对象内部实现 CRUD 逻辑的领域对象模式