竞价案例显示业务想要的粗粒度组装单元和技术拆出的细粒度服务经常对不上

一个银行资金内部竞价的虚拟案例，具体展示了”面向操作实现的 细粒度拆分”和”面向业务组装需求的粗粒度划分”之间真实存在的 落差。竞价流程被建模为发布竞价通知、分行申报竞价意向、总行 确定竞价结果这3个任务，如果按常规做操作级设计，用例分析后 很自然会把这3个任务拆分成9个细粒度服务——对技术人员来说这是 一种完全合理、具有”构件化”特征的组装，也符合SOA架构风格。但 如果站在企业级、多产品线的视角深入理解业务，会发现这套细粒度 拆分和业务人员实际想要的”组装”单元存在真实差异：业务人员需要 的很可能是把”竞价通知”和”意向管理”分别做成两个可以独立组装 的构件——因为有的金融产品同时需要竞价和意向两个环节，有的 产品可能只需要意向环节而不需要竞价，还有的产品两个环节都不 需要；而”EVA计算”这个操作级服务反而具有比其他服务更广泛的 复用能力，可能会在其他业务领域的很多不同流程环节里被反复用到。 重新按业务组装需求设计后，这个案例最终可能只需要两个较”粗”的 流程构件加一个具有更强通用性的纯能力构件，对应重构后的服务 数量也从9个压缩到3个——这个结果和基于DDD做微服务划分的结果 很相似，但上手门槛更低。这个案例说明，判断颗粒度合不合适， 不能只从”操作步骤怎么拆更整洁”这个技术视角出发，而要回到 “业务实际的组合需求长什么样”这个问题上来。

结构图：

flowchart TB
    subgraph 技术操作视角
    A1[发布竞价通知] --> S1[拆成多个细粒度服务 共9个]
    A2[申报竞价意向] --> S1
    A3[确定竞价结果] --> S1
    end
    subgraph 业务组装视角
    B1[竞价通知 构件] -.部分产品需要.-> P[各产品灵活组合]
    B2[意向管理 构件] -.部分产品只要这个.-> P
    B3[EVA计算 通用能力构件] -.多领域复用.-> P
    end
    S1 -.重构.-> B1
    S1 -.重构.-> B2
    S1 -.重构.-> B3
    B1 --> R[重构后仅需3个服务]
    B2 --> R
    B3 --> R