专有名词清单
1️⃣ 软件设计与架构原则类
| 缩写 / 名称 | 全称 | 核心含义 | 在系统设计中的作用 |
|---|---|---|---|
| SOLID | 单一职责 (SRP)、开闭原则 (OCP)、里氏替换 (LSP)、接口隔离 (ISP)、依赖倒置 (DIP) | 面向对象的五大原则，确保模块结构合理、易维护 | 让每个类或模块有单一职责、低耦合、高内聚，提升扩展性 |
| DRY | Don’t Repeat Yourself | 避免重复逻辑，鼓励抽象复用 | 减少维护成本，防止不同地方的逻辑不一致 |
| KISS | Keep It Simple, Stupid | 保持设计简单，避免复杂化 | 让代码逻辑清晰易懂，避免过度设计 |
| YAGNI | You Aren’t Gonna Need It | 不提前实现当前不需要的功能 | 防止系统膨胀，集中精力在当前目标上 |
| SoC | Separation of Concerns | 将关注点隔离成独立模块 | 使 UI、业务逻辑、数据访问等职责分层 |
| PoLA | Principle of Least Astonishment | 最少惊讶原则 | 让系统行为符合用户直觉，避免意外行为 |
| PoLP | Principle of Least Privilege | 最小权限原则 | 角色权限只限于完成任务所需范围 |
| GRASP | General Responsibility Assignment Software Patterns | 分配类和对象职责的模式集合 | 指导如何分配职责（Creator、Controller 等） |
| CQS | Command Query Separation | 命令与查询分离 | 避免方法既修改状态又返回数据 |
| CQRS | Command Query Responsibility Segregation | 命令和查询使用不同模型 | 提升可扩展性和性能，在大型系统架构中常用 |
| Layered Architecture | 分层架构模式 | 系统按不同职责分层（表示、业务、数据） | 清晰定义不同层的职责，易于维护 |
| Hexagonal Architecture | Ports and Adapters | 核心逻辑与外部接口解耦 | 提高测试性与可替换性 |
| Clean Architecture | - | 分离业务逻辑与外部实现 | 保证核心逻辑独立于框架和数据库 |
| Microservices Principles | - | 小型、自治、可独立部署的服务理念 | 降低复杂度，方便扩展与维护 |
| Event-Driven Architecture (EDA) | - | 基于事件的解耦架构 | 提高系统响应性和可扩展性 |
2️⃣ 代码质量 / 重构 / 精益类
| 名词 | 全称 / 含义 | 在架构中的作用 |
|---|---|---|
| CQS | Command Query Separation，命令查询分离 | 避免方法既修改状态又返回数据，保持读写逻辑独立，提高代码可维护性与单一职责的清晰度 |
| CQRS | Command Query Responsibility Segregation，命令与查询责任分离的架构模式 | 在复杂系统中分离写操作与读操作，提高性能、可扩展性和并行处理能力 |
| TDA | Tell, Don’t Ask（封装与面向对象最佳实践） | 鼓励对象自己完成任务而不是暴露内部状态，增强封装性，减少外部依赖 |
| BDUF | Big Design Up Front，前期大规模设计（一般负面评价，反面是渐进设计） | 在项目开始阶段就完成整体架构与细节设计，适用于需求极为明确且变动小的场景 |
| MVP | Minimum Viable Product，最小可行产品 | 快速验证系统架构与核心功能的可行性，降低初期投资风险，为后续迭代建立基础 |
| FIP | Fail in Place，局部失败原则（系统容错） | 系统某部分失败时，其他部分继续运行，提升架构的容错能力与可用性 |
| EAFP | Easier to Ask Forgiveness than Permission，更容易先尝试再处理错误（典型 Python 风格） | 允许先执行操作，如果失败再处理异常，减少前置检查，提高运行效率（但需保证异常处理完整性） |
| LBYL | Look Before You Leap，先检查再执行（EAFP 的对立思路） | 在执行操作前进行条件判断与验证，适用于错误成本高或安全性要求高的架构场景 |
3️⃣ 安全 / 运维 / DevOps 类
| 名词 | 全称 / 含义 |
|---|---|
| OWASP | 网络应用安全组织，提供安全最佳实践 |
| CSRF | Cross-Site Request Forgery，跨站请求伪造 |
| XSS | Cross-Site Scripting，跨站脚本攻击 |
| SQLi | SQL Injection，SQL注入 |
| CSP | Content Security Policy，内容安全策略 |
| RBAC | Role-Based Access Control，基于角色的访问控制 |
| IAM | Identity and Access Management，身份与访问管理 |
| CIA | Confidentiality, Integrity, Availability，信息安全三要素 |
| AAA | Authentication, Authorization, Accounting，鉴权与计费体系 |
| DevSecOps | 开发-安全-运维一体化方法论 |
4️⃣ 团队协作+敏捷类
| 名词 | 全称 / 含义 |
|---|---|
| Agile | 敏捷开发方法论总称 |
| Scrum | 敏捷开发框架 |
| XP | Extreme Programming，极限编程 |
| TDD | Test Driven Development，测试驱动开发 |
| BDD | Behavior Driven Development，行为驱动开发 |
| DDD | Domain Driven Design，领域驱动设计 |
| CI/CD | Continuous Integration / Continuous Delivery，持续集成与交付 |
💡 总结
你问的这种“简短代号型”原则和理念，在开发规则、架构思想、安全规范、团队方法论几个领域非常多。
你的角色提示词，就可以写
注意，写提示词，很多软件设计理论存在一些互斥性。你丢太多设计名称，AI势必会造成 左右脑互搏。
丢个AI一些软件设计规则，有助于设计出避开各种含有缺陷的设计。
你是一位经验丰富的资深 Java 开发者。你始终遵循 SOLID、DRY、KISS 和 YAGNI 原则。你始终遵循 OWASP 最佳实践。你总是将任务分解为最小的单元，并以循序渐进的方式解决任何任务。
特殊说明：
上述文章均是作者实际操作后产出。烦请各位，请勿直接盗用！转载记得标注原文链接：www.zanglikun.com
第三方平台不会及时更新本文最新内容。如果发现本文资料不全，可访问本人的Java博客搜索：标题关键字。以获取最新全部资料 ❤
免责声明： 本站文章旨在总结学习互联网技术过程中的经验与见解。任何人不得将其用于违法或违规活动！所有违规内容均由个人自行承担，与作者无关。
第三方平台不会及时更新本文最新内容。如果发现本文资料不全，可访问本人的Java博客搜索：标题关键字。以获取最新全部资料 ❤
免责声明： 本站文章旨在总结学习互联网技术过程中的经验与见解。任何人不得将其用于违法或违规活动！所有违规内容均由个人自行承担，与作者无关。
