鲁棒图与设计类图区别及含实体控制边界类的类图咨询

• 鲁棒图（也叫健壮性图）不是UML官方规范定义的标准图类型，它是ICONIX软件开发流程中特有的过渡性分析产物，位于需求分析到初步设计的衔接阶段，抽象层级很高，仅用来划分三类元素的职责边界、梳理核心交互路径，不会定义类的属性、方法、可见性、关联多重度这类实现细节，本质是分析阶段的草图工具。
• 设计类图是UML标准明确规定的静态结构图，属于详细设计阶段的正式交付物，核心目标是输出可直接指导编码的类结构定义，必须明确每个类的完整属性、方法、访问权限，以及类之间的精确关系（泛化、实现、依赖、关联、聚合、组合）和关联多重度，抽象层级远低于鲁棒图。

• 鲁棒图本身的核心价值就是给后续详细设计做铺垫，它对边界类、控制类、实体类的三类职责划分逻辑是行业通用的类职责拆分准则，参考鲁棒图的示例可以快速规避类职责混乱的问题：比如不要把业务逻辑写在边界类里、不要把交互逻辑塞到实体类里。
• 参考时需要注意不能直接照搬鲁棒图的粗粒度结构：鲁棒图里的单个控制类往往对应一整条业务流程，设计类图里需要按照单一职责原则拆成多个粒度更细的具体服务/控制器类；鲁棒图里的连线仅代表“存在交互”，设计类图里需要明确对应关系类型，补全所有实现层面的细节。

以下为电商场景「用户提交订单」流程对应的设计类片段，完全覆盖边界、控制、实体三类元素：

元素清单 #

• 边界类（负责和外部参与者、第三方系统交互，不承载核心业务逻辑、不存储核心业务数据）
  • OrderSubmitPage：前端订单提交页类，核心方法：loadDefaultReceiveAddress()、validateSubmitFormParam()、sendSubmitRequest()
  • ThirdPaymentAdapter：第三方支付网关适配类，核心方法：requestPayChannelToken()、parsePayCallbackNotify()
  • UserNoticeComponent：用户消息推送类，核心方法：sendOrderCreateSuccessSms()、pushOrderStatusChangeMsg()
• 控制类（负责业务流程编排、业务规则校验，是连接边界类和实体类的中间层）
  • OrderSubmitProcessService：订单提交流程编排类，核心方法：execSubmitProcess()，内部按顺序执行参数校验、库存锁定、订单生成、支付单创建、消息推送全流程
  • StockLockService：库存锁定服务类，核心方法：lockSkuStock()、rollbackLockedStock()
  • PayOrderBuildService：支付单构建服务类，核心方法：generatePayOrder()
• 实体类（对应核心业务数据模型，一般和持久化存储结构直接映射，承载核心业务状态）
  • User：用户实体，核心属性：userId、nickname、phone、defaultAddressId
  • Order：订单主实体，核心属性：orderId、userId、totalAmount、orderStatus、createTime
  • OrderSkuItem：订单商品明细实体，核心属性：itemId、orderId、skuId、buyCount、skuSnapshotInfo
  • SkuStock：商品库存实体，核心属性：skuId、availableStockCount、lockedStockCount
  • PayOrder：支付单实体，核心属性：payId、orderId、payAmount、payStatus、expireTime

核心关联关系 #

1. 边界类OrderSubmitPage依赖控制类OrderSubmitProcessService，将用户提交的表单参数传递给后者处理
2. OrderSubmitProcessService分别依赖StockLockService、PayOrderBuildService、UserNoticeComponent完成各流程节点的逻辑调用，同时关联User、Order、OrderSkuItem、SkuStock、PayOrder实体类完成数据的读写操作
3. PayOrderBuildService依赖边界类ThirdPaymentAdapter，完成和第三方支付渠道的交互逻辑
4. 实体类间的固定关系：Order和OrderSkuItem为组合关系（订单删除则对应商品明细同步删除），Order和PayOrder为一对一关联，Order和User为多对一关联，OrderSkuItem和SkuStock为多对一关联

内容的提问来源于stack exchange，提问作者qrttttt