用例备选流中新增类与方法：主域模型还是备选域模型？

嘿，这个问题在需求建模和领域设计的实践里其实挺常见的，我来给你梳理清楚判断逻辑和实践方案～

关键要区分这些新增的类和方法，是属于核心领域的固有组成部分，还是仅服务于某个特殊场景的临时/边缘逻辑，不同情况对应不同的处理方式：

1. 若新增元素属于核心领域，或具备复用性 → 合并到主领域模型和序列图 #

如果这个备选流的逻辑是业务中普遍存在的分支场景，或者新增的类/方法是领域里本来就该存在的实体、值对象或行为（只是主用例没覆盖到），那必须把它们整合到主领域模型里。
举个例子：主用例是「用户提交订单」，备选流是「用户使用会员积分抵扣下单」，新增的MemberPoints类和deductPoints()方法，显然是核心订单领域的一部分——没有积分抵扣，订单业务的完整性就打了折扣。这种情况下，不仅要把类加到主领域模型，序列图里也应该用UML的alt（分支）片段来展示这个备选流的交互，和主流程放在同一张图里，让逻辑更连贯。

这么做的核心原因是：领域模型要完整反映业务的核心概念体系，不能因为是备选流就割裂领域知识，否则后续维护时会出现模型碎片化的问题，其他开发者看模型时很容易漏掉关键的领域元素。

2. 若新增元素是临时/边缘场景专属 → 创建备选领域模型（或做扩展标注） #

如果这个备选流是极端异常场景或者仅在特定小众场景下触发，新增的类/方法完全不涉及核心业务逻辑，只是为了处理这个特殊分支，那可以单独创建备选领域模型，或者在主模型里用灰色标注、备注说明的方式标记为「扩展元素」。
比如主用例是「用户支付订单」，备选流是「支付网关完全崩溃，触发临时缓存订单并通知运维的逻辑」，新增的EmergencyOrderCache类和cacheAndAlert()方法只在这个极端场景下生效，平时业务根本用不到。这种情况下，就没必要污染主领域模型，单独做一个备选模型来展示这个分支的领域元素即可，序列图也可以单独画这个分支的交互（或者用opt片段附在主序列图末尾）。

这么做是为了保持主领域模型的简洁性，让它聚焦于核心业务流程，避免被过多边缘逻辑干扰。

实践中的小Tips #

• 序列图层面，除非备选流完全独立于主流程且异常复杂，否则优先用alt或opt片段在主图里展示分支逻辑，不用单独新建序列图，这样能让整个流程的关联性更清晰。
• 拿不准新增元素是不是核心领域？可以问自己一个问题：「如果把这个类/方法去掉，核心业务逻辑还能正常跑通吗？」如果不能，那它就是核心的，必须合并；如果只是某个特殊场景的补充，那可以考虑单独处理。

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