DDD领域驱动设计系列-原理篇-战略设计

概述

DDD领域驱动设计是架构方法论，适用于业务逻辑较复杂系统。

DDD核心目的能输出领域如何划分，确定核心域（确保重点资源投入），通用与支撑域，以及架构分层如何构建。

本文章系列会分2部分讲述DDD：1、DDD原理；2、DDD实践。DDD原理分为战略及战术设计2篇来讲述；

架构的本质上就是通过定义不同组件及组件间的关系实现高扩展性，可维护性，控制复杂度（手段）；最终通过架构来实现高效迭代(目的)；比如一个支付渠道的接入是否能影响最小的组件来实现扩展。

而DDD通过战略设计来划分出业务域，定义不同域间的关系以及产出问题域领域模型；这样相同域的业务需求能在一个业务域完成而不会影响到其它域，无论从开发&测试&部署维度都能影响最小。

DDD通过战术设计通过战略设计产生的领域划分及问题域领域模型做为输入，输出确定架构分层：Clean架构，CQRS等。

原理篇整体以战略设计及战术设计做为2大章节来叙述。

战略设计

目的

产出领域模型，领域的划分，定义核心域，通用域，支撑域。最终实现：控制业务架构复杂度，提供高扩展&可维护性，从而提升业务迭代效率。

概念

领域：企业要做事情集合。包含了业务流程，角色。如结算域就是一个领域，结算域涉及很多业务流程：如运营设置费用项，商家入驻生成结算合同，交易确认收货进行结算给平台及结算给商户。

子域：领域的细分。细分的目的是为了控制复杂度。如结算又可根据结算阶段分为收单，计费等子域。

核心域：企业核心能力，需要投入重点资源来跟进；比如电商中交易，供应链，支付。

通用域如用户权限域，通用域可供不同业务使用。

支撑域：电商中的服务，在垂直电商刚起步时，服务可以做为支撑域采用采购形式让业务整体能run起来。后续根据业务发展，服务变成关键要素，此时服务再提升为核心域投入重点资源进入升级。

限界上下文：是业务的边界。包含若干领域或子域。在业务边界内同一个实体拥有同一个语义。原则上限界上下文必须包含完整的业务流程。如结算中的计费子域对应一个限界上下文，其中包含了运营设置计费项以及后续确认收货后计费业务流程。

怎么划分

1、领域模型确定

通常使用事件风暴来进行，如结算业务中，事件风暴如下。

2、限界上下文划分

根据领域模型业务职责分类及相关性，最终能形成计费，清算，结算，合同上下文，结算用户上下文；

费用项&费用项实例及明细&计费单合到计费限界上下文。why？本质上费用项及计费单都是做的计费的业务事情。费用项是计费的基础。反过来如果费用项拆到其它限界上下文会发现计费的这个需求会涉及到2个域，增加了协同成本。费用项是运营设置哪种业务模式有哪些费用项，如平台b2b会有平台抽佣及商家货款2个费用项；费用项实例则是针对费用交易对手（商家）设置的个性化费率的费用，如KA商家A费率会设置成10%，商家B费率设置成5%；

结算账号由商家开通，因此这块单独在结算用户域中，是结算前置条件；

由于商家与财务视角看到的计费项不同，所以以商家视角单拆出清算限界上下文。

结算单对应到结算限界上下文中，这中间的语义有结算单：核心定义给商家在什么时候结算多少钱。打款单对应到打款限界上下文，对应一笔实际与出资渠道对应的一条打款流水单。

3、由限界上下文再合并成子域

计费上下文形成计费子域。清算限界上下文形成清算子域。

结算及打款合成一个结算子域：结算单与打款单需要高频协同因此从团队协作上及代码维扩展上放在一个子域。

合同及结算账号上下文则形成结算结算用户子域。原因：从职责看都是维护商家的信息，从商家入驻到维护结算合同及结算账号整体能在这个子域形成闭环，合能减少协作成本；

4、确实问题域的领域模型

这步核心确定问题域领域模型有哪些核心要素及模型间关系是什么；

实际模型在落地时还需要考虑到性能，存储及其它因素，这块在战术设计中会做考虑并最终产出解决方案模型。如在实际落地时我们在接收交易确认收货消息进行结算时为了适配不同的业务方（如行业A，行业B）以及保证结算前的数据有据可依此时会产生结算收单的模型；