DDD战略设计：价值模型决定划分，追求业务耦合而非重用

DDD书籍本身没有给出战略设计的具体过程指导，可以借用[[业务建模的层层展开：价值模型→服务蓝图→业务流程图|业务架构设计]]的方法来补上这一环。第一步同样是绘制价值模型，它决定了领域和子领域的划分——通常每个产品/服务代表一个领域，价值流图里的每个环节对应一个子领域；划分子领域有两种思路：按部门职能拆分（比如把价值流按研究、投资、交易等环节拆，通常至少拆到部门级别，再往下粒度可能过小）、按业务流程拆分（比如产品管理服务按研/募/投/管/退这些流程阶段拆分价值流）。第二、三步同样是绘制服务蓝图和业务流程图，这两步决定了微服务的拆分（拆分思路同[[应用拆分先看业务定位，整合看三个维度反向检验|应用架构]]）。第四步绘制分层次的模型（跨领域模型、领域模型、应用模型）。第五步是应用/数据/技术架构设计，但DDD在应用架构风格上和传统微服务架构有明显差异：传统微服务架构通常先纵向（技术）分层，再横向（业务）解耦——这种分层有利于重用，但代价是更高程度的耦合，因为纵向层与层之间通常按交易请求的执行顺序串联，一处变更容易引发其他层级连锁变更；DDD架构风格追求的是业务的高度耦合而非重用，因此会先做横向（业务）解耦形成独立的微服务，微服务内部再有两种划分方法——一种是内部不再拆分，展示层/应用层/领域层/基础设施层都放在同一个微服务内；另一种是仅做前后端分离，前端独立成应用，应用层/领域层/基础设施层放在一个微服务里。DDD提供的六边形架构、洋葱架构本质上都是类似的思路。可迁移启发：判断一个团队自称”用了DDD”是不是名副其实，可以直接看它的应用架构风格——如果依然是先纵向按技术分层、再横向按业务切，本质上还是传统微服务的重用优先思路，并没有真正体现DDD追求业务高内聚而非技术重用这个核心取向。

结构图：

flowchart TB
  V["价值模型决定领域/子领域划分"]
  V --> D1["按部门职能拆分(如研究/投资/交易)"]
  V --> D2["按业务流程拆分(如研/募/投/管/退)"]
  S["服务蓝图+业务流程图决定微服务拆分"]
  A["应用架构风格对比"]
  A --> T1["传统微服务:先纵向技术分层,再横向业务解耦<br/>=有利于重用,但代价是更高耦合(连锁反应)"]
  A --> T2["DDD:先横向业务解耦形成微服务<br/>=追求业务高内聚而非重用"]