DDD之于业务支撑的意义
阿甘：我也不知道，只是想跑而已。 追随者：感觉这样做是有意义的，而且阿甘也还在前面领跑。
无论做业务，还是做平台、中台，大家常常会被交错复杂的业务逻辑、晦涩耦合的业务代码搞得心力憔悴。我想，大家对DDD的追求，也是对轻松支撑业务发展的诉求，在探寻有没有合适的理论可以改善现状。毕竟，美好生活，共同向往。
▐ 现状：分层支撑机制
基础能力：相对原子的能力是基础（域）能力，这个可以较好地支持业务定制。由于比较基础，表达的产品能力范围也是很大的。但是，一个完善的产品需要串联的基础能力是非常多的，串联的成本也是非常高的。
平台产品：基础能力的通用性，意味着缺少对场景的理解，缺少了进一步提升生产效率的“基因”。所以在交付的时候，会基于一些高频场景进行抽象，形成平台的产品能力，争取做到“拆箱即用”。业务基于“平台产品”这层进行定制的时候，理解成本会大大减少。
分层支撑框架
▐ 腐化：业务逻辑渗透
这样的层次，看上去很美好：在起步阶段，由于缺少历史包袱，的确可以提升一定的生产效率，这是能力本身的收益。但是，越往后，随着业务接入的增多，业务之间开始互相影响，研发的阻力也越来越大。
这样的过程，违背了我们”希望通过业务场景，丰富平台能力，同时保证内核干净“的初衷。能力应该是基于相对多的用例、相对完善的思考进行抽象，是横向统一看，有更深刻的理解，但是垂直的交付，让我们更加纵向地处理问题，往往只是“窥探”了链路，在交付时长和业务节点的限制下，很难想得更加全面、深刻，难以做出更通用的设计。
那么，为什么关注DDD？如果说DDD直击了软件复杂度的核心——“问题域”，那可能还是比较抽象。具体来说，因为这的确符合我们追求的价值观【提升长期的生产效率】：
细分领域，培养专业的人、事：因为DDD的核心是要求让各个领域做好理解和封装，把一个业务需求拆解、安放在各自合理的地方，通过这样的分解与沉淀，保证了领域的输入，能够得到长期可持续的发展，形成竞争力。
机制保障，不依赖易变的事物：DDD其实在总结很多通用的技巧和经验，能够让这样的实施更具有确定性。无论是聚合根对领域实体的管控能力、限界上下文的交互策略、领域内核的抽象地位...等等，一旦选择尊奉，确定下来，就能够落在代码结构、组织关系、团队文档中，形成共识，不会因为人员等因素的变化而剧烈波动。
对DDD的关注，可以类比于我们对“工匠精神”的关注，对DDD的重视，也是我们对业务理解的重视。贴近业务，更要理解业务，不仅要理解业务，更需要理解大多数的业务。这样的追求，让我们往上看了一个层次，回归了最本质的问题：我们要解决什么问题？如何能够解决得更好？
不知道大家是否有这样困惑：DDD的学习过程好像是”大海捞针“的过程。即使能够捞到点东西，使用起来，还是会有种“东施效颦”的感觉，并不是很自然。为什么学习DDD那么困难呢？
▐ 感受：不得其门
叔孙武叔语大夫于朝曰：“子贡贤于仲尼。” 子服景伯以告子贡，子贡曰：“譬之宫墙，赐之墙也及肩，窥见室家之好；夫子之墙数仞，不得其门而入，不见宗庙之美、百官之富。得其门者或寡矣，夫子之云不亦宜乎！”
正如要感受到孔子达到的境界，自己的学问也需要有一定的积累。我们要感受到DDD的力量，自己本身就要成长到一定程度（如：经历了一些成功或者失败的设计，有自己的经验或者教训），才能形成共鸣和认同。
工作中，的确很少看到DDD的最佳实践。在复杂的业务面前，谁也没有勇气说，哪个软件结构是理想的设计：
因为这不是一个确定性的问题分解，你的设计会被放在显微镜下研究，总能找到各种反例。 而且，我们深知，最佳的实践，一定是做得足够的“软”，对扩展留有设计，能够随着业务发展而迭代，不是一个静态的结果。
我们有一种困惑，到底怎么样算是DDD：
实践的个例，难以信服：当我们看到”DDD实践“的时候，可能会发问：这也算DDD？不就是一个正常的服务端框架与方案，也无法涵盖其它的场景或者部门系统。
抽象的理论，觉得空洞：当我们看到”抽象的DDD定义与策略“的时候，可能会发问：这也算DDD？不就是一些软件设计的共识，然后强加了一些名词定义，有些策略与我们手上的系统也并不匹配。
无论往抽象看，还是往具体实现看，都很难找到令人信服的理论与实践（能够有确定性的落地能力）。因为这不像23个设计模式那样，可以通过N个模版就能涵盖大多数的模式。
为什么不能产生特定的模式呢？可以结合下图进一步来看：
抽象理论：如同抽象的接口一样，"DDD理解"最上面的学习主要是理论定义，比如：聚合根、值对象、资源库、核心域、支撑域等各种定义，这些是易于理解掌握的。
通用实践：如同相对具体的抽象类一样，"DDD理解"中间层次是一些通用原则和技巧，比如：上下文的映射策略、架构的选择等。这些因素是确定的，但需要自主进行取舍与选择，并且需要与时俱进，增量的部分需要你自己学习补充。
具体实践：如同具体的类实例一样，"DDD理解"中下面层次是一系列的具体实践，结合各自的业务场景，进行了不同因素的设计、取舍与补充。因为涉及的选项较多，造成最终的选择结果往往是发散的，令人感觉“千人千面”。
两者不同的地方是：
“代码抽象层次”中层次关系是比较明确的，且有约束。
“领域驱动理解层次”中无法提供明确的约束，都是多个策略的取舍、一些关键的建议。
因此，由于问题的抽象层次较高，各种策略的不确定性较高，很难在DDD中产生像”23个设计模式“那样精炼的模式。一定要有的话，也是一系列的模式，比较发散。
因此，我们渐渐明白：DDD面向的是软件的“软”，涵盖方方面面。DDD的深入理解，需要“千锤百炼”后，才能明白那些深入简出的建议，才能体会那句“师傅领进门，修行靠个人”的真言，才能感受到“众里寻他千百度，那人却在灯火阑珊处”的美妙瞬间。
基于设计原则看DDD
单一职责是说：一个类应该只有一个发生变化的原因。职责的单一，可以更好地内聚，减少耦合，方便演化。
DDD里面的领域划分可以类比思考。对领域的划分，无论是按领域实体，还是按照功能模块，还是按照服务等划分，其实都想尽量保证领域的正交，能够独立演化和发展。
可以整体作为1个部分。
可以按竖着的正、负切分2个部分：上面1个（红），下面2个（黄、绿）。
可以按横轴的正、负切分2个部分：左边1个（黄），右边2个（红、绿）。
可以切分成3个部分（红、黄、绿）。
聚类的例子
开始的时候，可能只是一个大交易，比如：支付开始的时候只是买卖双方自己协议，也不需要建模。 后面支付发展了，也就独立出来一个域。原来不需要专人维护，后面会渐渐拉出一个团队来承接相关研发。
初始化：按照的经验初步的划分，也可以是行业标准（没有行业标准的时候，就只能靠经验了）。 花费评价：生产、交付过程的人力成本度量，关注理解成本、开发效率、系统稳定性、运维成本等因素。 更优解：在业务发展过程中，计算花费评价，分析影响评价的“好因素”、“坏因素”，进行进一步调整。
调整的内容：其实是匹配生产关系。 调整的原则：追求职责的内聚，精细化分工。 不断调整的原因：业务在发展，内聚的标准需也要与时俱进。
开闭原则是说：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。也就是说，对扩展区块是要有设计的，扩展的部分不应该影响稳定逻辑。
在DDD中，实体的行为，在保证对外封闭的情况下，也是需要考虑扩展能力的。
Open Closed Principle：开闭原则
影响较大：很难有勇气去频繁地修改一个核心类。 过于集中：随着方法和逻辑的增多，实体越来越臃肿。 场景较多：很多逻辑并不是正交的，不是 if 这样 else 那样的，充满着交集与叠加。
原来 get set 写法很舒服的本质在于，很多的扩展被放在了业务脚本中，业务脚本虽然千疮百孔，但是是在应用层，远离核心逻辑。底层模型、通用组件等基础逻辑还是比较干净的。 应用DDD的时候，把一些行为下沉到领域层之后，也是要考虑扩展的。如果只关注收口，不关注扩展，那的确是“画地为牢”、“捡了芝麻，丢了西瓜”。
Liskov Substitution Principle：里氏替换原则
资源库的替代性需求
本地部署：线下零售交易为了服务稳定性，期望可以具备本地保存数据的能力。 云上产品：售卖给外部企业的交易产品，成本的要求也不尽相同，期望在云上采购不同的存储服务。
这些场景，让大家逐渐深信：当面向更广阔的市场，基础设施也是充满着不确定性，需要具备可替换的能力。
存储实现间的复用策略
在具体实现的过程中，并不是每个领域都会独立部署，有些领域因为组织、性能的因素会一起部署。往往这些领域的代码也是在一个项目模块中的。出于横向效率的考虑，会设计统一的存储框架。
不同设施的存储能力不同，但整个存储流程又是类似的（协议转换，存储语句生成、执行与事务，返回结果），这样在不同存储能力的过程复用方式上需要进行取舍（数据库、Tair等是分开抽象还是统一抽象）：
如果“大一统”为主，那么针对关系型存储、KV存储等不同存储进行抽象的时候，就会和“长方形与正方形的问题”一样犹豫：
收益：如果你长期维护，了解里面的特殊性，的确是可以省略一些主体代码，提高开发效率。
代价：但大多数人要做扩展的时候，会感到很多不解，有很多本不需要的适配，充满迷惑。
如果以组合为主，那么可以通过多套模版，更好地进行自主选择。这样分而治之，减少了大家的理解成本，也能独立演化，更能适合存储的能力特性。但是需要沉淀多套理解，往往也缺少人力支持。
我想，“基于不同的存储能力，设计不同的模版框架” 应该是首选。大一统的抽象，开始时，人力成本可能低一点，但因为抽象层次较高，在理解与维护上将是一个“人力成本黑洞”，随着时间的推移，会降低整体收益，长期看是得不偿失的。反之，不同的模版复用，最终可以获得更好的整体收益。
▐ 迪米特法则：领域协作
域能否成为协调层
“交易域”看上去是负责整个交易过程，可以协调各个域，逻辑上比较合适成为协调者，但是主要还是在管理订单，其它赋予的协调能力，这部分并没有领域实体。 “订单域”看上去只是负责订单本身的服务，不太关心其他域，但是因为订单合约上有着所有合约信息（无论是直接还是间接持有），这意味着，“订单域”本身就有协调的潜力，只是职责看上去不够单一而已。
协调层能否成为域
逻辑上个人是认可纯靠理解作为一个域，毕竟知识本身也是一种资产。
但实际上，没有载体，就做不了特别多事情，包括状态记录，数据服务等，只能辅助，没有核心竞争力，难以生存下来。
协调层的名称
没有规矩，难成方圆
之前在业务部门做业务的时候，并没有业务活动、流程等相关概念，往往是基于业务需求写业务脚本，经验的多少会影响代码的优雅。但除了经验，大家并没有比较好的结构框架、原则，去承接应用层的各种业务逻辑，因此也充满疑惑：
对外服务接口应该如何切分？
类似服务之间是否可以共用流程？
业务执行过程如何进一步结构化切分？
......
没有规范的结果是，往往各有各的看法，谁都想立一套结构，谁也不服谁起的一套，各有各的代码区域。
平台的稳定框架
现在工作中，因为在平台，平台思考和治理的时间也比较久了，也有比较稳定的共识。整体的设计，在业务入口和业务入口之间、业务入口和稳定逻辑之间，预留了空间和扩展能力去承接场景化的逻辑，结构也比较确定：
入口按业务活动切分：服务入口按照业务活动扩展，核心理解并关注用例，什么角色要干什么事情。
流程独立承接与编排：业务活动在到达复用层（如：领域服务、外部服务、业务扩展）前保持独立，各自编排。
借助流程文件编排执行过程：将执行过程切分为执行节点，节点的切分可以以“功能点”、”涉及的域“、“涉及的实体“等为依据。节点间的共同能力下沉到基础能力中。
......
反复review形成共识
分而治之，缩小大家的关注点，更好地切分协作，这样的确很容易理解并接受。但是要保证合理的切分，还是要有统一的共识和原则。
往往一致的形成，不是先一致共识，再切分，而是初步沟通后就尝试切分，再review达成一致，在曲折中前进。如果大家的看法、冲突较大，那么这个共识达成的过程就相对较慢。好在，这种切分也不是时常发生，也就大需求、大重构的时候。此时，预留的研讨时间、开发资源也是充足的。
依赖倒置原则：六边形架构
依赖倒置原则是说：程序要依赖于抽象接口，不要依赖于具体实现。
以领域为中心，其实是一个比较重要的转变：
原来以分层架构为主：讲究按层次去看，尽量将能力下层，进行更多工具复用，积累的是通用组件。
现在以领域为中心：讲究按抽象层次去看，尽量将理解融入到领域核心，进行更多“理解”复用，积累的是业务知识。
这样的转变，让我们有意识地将“领域理解”作为核心，形成行业竞争力，把“知识”作为资产进行售卖。
为了保证领域内核的抽象，需要定义好领域内核的边界，有两类接口：
对上游提供的能力：通过接口声明，说明能承担的职责，在领域内部进行实现支撑。
对下游的能力依赖：外部服务、业务扩展定制、存储服务都可以作为下游服务看待，通过接口声明服务依赖。
可以看到，领域内核与外部之间通过接口进行解耦。对于更基础的服务，会被视为和业务入口一样的外部端口，属于应用层。比如，存储服务：
原来更多的是基础能力：数据框架 + DO，不需要理解转换，转换在上游完成，DO 也会作为核心模型被上游使用，在采用遵循模型策略的时候，上游完全使用 DO 作为核心对象进行流转。
现在可以理解为“业务组件“：需要实现领域的存储接口，承担协议转换，将领域对象转换为数据存储对象DO，DO也不会被领域直接理解，需要转换为领域对象再往外透，被领域内核定义了表现。
对DDD的追求，来自我们渴望优雅地解决各种业务问题，希望有一套框架可以引导我们去分解问题，得到稳定、高效的生产效率。
但是这好比对“永动机”的追求，是一个难以有肯定答案的过程。能够解决软件复杂性的方案，必定是结合相关场景并且不断演化的，单纯追求DDD是得不到“银弹”的。
不过正如对“永动机”的研究，能让我们关注能量的转换过程，可以引导我们制造出更加高效的能源机器。对DDD的研究与追捧，能够让我们更加关注对业务的深刻理解，可以引领我们写出更加易于扩展的代码实现。
我想，正是“业务的不断发展”、“软件的复杂性”的存在，才让编程充满了挑战，才让大家对框架的研究充满热情，这何尝不是一个美妙的事情。
我们是大淘宝技术-交易平台团队。团队主要从事交易链路交付工作，在交付工作中，抽象和建设横向产品能力（如：预售、电子凭证等），团队关注业务架构、DDD等理论与实践，致力于高效、稳定地实现业务接入，并抽象赋能。