面向对象分析与设计（OOAD）是从用户行为与业务本质出发，经业务模型（用例图、实体类图）、系统设计（职责划分、时序图）到Java代码的逐层映射过程，全程强调业务语言优先、模型可验证、代码是设计的忠实实现。
面向对象分析与设计（OOAD）不是从写 class 开始的，而是从“用户在做什么、为什么这么做”出发，一层层剥开业务本质，再逐步落到 Java 代码上的过程。它强调用现实世界的视角去理解问题，而不是一上来就考虑数据库字段或 Spring Boot 怎么配。
业务需求 → 业务级模型（说人话）
这一阶段完全不用 Java 关键字，只谈业务角色和动作。比如电商系统中，客户说：“我要下单，但库存不够时得提醒我。”你就画出业务用例图——参与者是“顾客”，用例是“提交订单”，并注明它依赖“检查库存可用性”。类图里只出现“顾客”“商品”“订单”这些实体，属性也只写“顾客姓名”“商品价格”“订单日期”，不写 String name 或 @Column。关键是要让业务方能看懂、能确认。
业务模型 → 系统级设计（定边界、分职责）
进入设计阶段，开始引入技术语境。同一个“提交订单”用例，现在要拆解为：前端调用 OrderController.create() → 调用 OrderService.placeOrder() → 再调用 InventoryService.checkStock()。这时画设计级类图，就要标清方法签名、接口契约（如 PaymentGateway.process()）、以及哪些类该持久化（加 @Entity）。时序图里对象变成具体类名，消息变成方法调用，状态图则明确“订单”从 PENDING 到 PAID 的触发条件和副作用（如扣减库存）。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
设计模型 → Java 代码实现（可运行、可验证）
代码不是凭空写的，而是对设计模型的直接映射。例如设计图中定义了 Order 类有 id、status、items 属性和 cancel() 方法，那 Java 类就该有对应字段、getter/setter 和逻辑；若设计中约定 OrderService 依赖 InventoryService，代码里就该用构造器注入或 @Autowired。工具如 PlantUML 可反向生成类图，IDE 调试时也能导出实际调用时序，用来核对是否偏离了设计意图。
立即学习“Java免费学习笔记（深入）”；
贯穿全程的关键习惯
始终区分“业务语言”和“技术语言”：需求评审时不说“Controller 层怎么接参”，而问“顾客取消订单后，已扣款的钱多久退？”
每个模型都要可验证：业务类图能否覆盖所有用户提到的名词？设计时序图能否解释清一次失败支付为何会重试三次？
Java 不是目的，而是载体：public class Order { … } 是结果，不是起点；真正重要的是这个类在业务中代表什么、和谁协作、生命周期怎么管理。
