DDD落地的思考–一切需求从领域出发

一、背景

这个点是在平时做需求的时候想到的，当然也是区别于常规的业务开发的思维角度，从标题上看像是有点虚夸的意思，但是如果认可DDD可以解决复杂度问题的话，不妨先读一读文中的内容。

二、业务背景

这里将业务背景分为多个场景，方便分别讨论

2.1 从0-1构建一些新系统

一般而言从0到1构建的新系统并不是特别难的事情，重点是新系统背后代表的相关领域活动能否被识别到，新系统意味着新的需求或者相关领域能力的构建，所以从领域的角度来讲是非常容易识别和实践的。

2.2 从1到N进行迭代

大多数情况下很少会遇到从0-1构建新系统的机会，所以从1到N可能更有技术挑战，一般而言不谈领域，采用常规方法进行迭代也不是不可以，只是不一定能全面的感知到整个业务领域的变化。所以从1到N之间的演进用领域驱动的方法去分析可能更好。

2.3 从N到0进行维护

这种场景其实不是很常见，因为很多微服务系统在业务萎缩到一定阶段或者即将完成其使命的时候就到了要下线的时候了，所以从N到0维护系统的话，常规的视角看可能就是换个系统，或者业务没有了，或者不重要了，在僵而不死的系统中进行迭代维护其实也比较难，可能就破罐子破摔了。但是另外一方面此类场景正好印证了领域随着业务变化而随时消亡或者被新领域替代的规律。从企业的角度来说此类系统更是极为鸡肋，但是也没有更好的方法去做系统功能的收缩合并，所以成本问题也是需要考虑的。

2.4 技术侧改造需求

有时候技术侧改造的需求可能并没有意识到是技术领域的变化，当然从技术的角度来说不是特别关心是不是从领域出发，但是实际上是对技术领域相关的内容做了更新来适应业务的需求。

三、出发点

如果一切需求都是从领域出发的话，那必然要划分多个上下文和领域，不同的部分由不同的团队和系统负责，对应实现交叉和协同。但是一个大的公司或者一个大的范围领域应该如何识别业务需求，寻找突破口呢？

3.1 业务流程

每次需求的变化都会导致业务流程出现新增，修改，上线，和下线，但是很多时候这方面的东西不论是产品还是技术都没有很好的把控不同系统的业务流程，类似于没有文档化，没有可视化，这方面的东西也比较杂，乱，多。所以需求一旦有变化或者提出新的流程的话那最好需要跟中下业务流程。这里其实也考研文档能力和文档管理系统的水平，画业务流程有如下几个工具可以使用到如Plantuml,ProcessOn的流程图，泳道图等。当然不太推荐思维导图。如何管理业务流程，个人觉得可以进行分层管控，如下图：这里从四个级别来划分业务流程文档的类型，不同级别的视角是不一样的，需要技术侧和业务产品侧一起构建。所以话说回来，不管是已有业务还是新业务，业务流程文档一定是要有的，对应于需求变更业务流程也需要记录更新。

3.2 模型变更

并不是每个需求都需要业务流程变更，当然也并不是每个需求都可能存在模型变更。这里强调的是模型的变更必然意味着系统的变更，同时也是业务需求的变更。从模型上入手去管理需求，结合领域上下文的话则可以方便的做到将需求管理域领域变化进行结合。这里的模型不仅包括数据库模型，业务模型，也包括接口模型和接口参数模型。有时候某个领域的接口或者模型参数变化必然会与另外一个系统或者领域发生联系，所以模型变更如果管理好版本的话，可以反推需求的清晰度，需求的迭代过程等等。

3.3 技术影响

有时候某些需求是技术侧推动的，但是技术上的变化其实对于当前的业务流程和功能可能没有多少影响，比如技术改造，升级。但是这隐含了一个领域，就是技术领域，在技术领域中有哪些子领域可以支持业务发展，保障持续性服务。所以在不同系统中的技术侧改造其实也是从技术领域来帮助业务领域更好的实现其价值，所以也印证了技术是为业务服务的。那么在技术影响方面上来说，新系统或者已有的系统改造都必然掺杂着技术因素，所以门槛会稍微高一点，产品，运营可能不需要懂太多的技术知识，所以从技术上的角度来看技术改造类的需求的出发点一定是技术领域中的某些部分。不同公司的技术领域中的东西大同小异，但是要发挥其能动性还需要领导层的推动和成本投入，比如技术文化氛围，技术栈储备和选型，技术人才的发挥，技术积累，复用，创新等。

四、落地限制

4.1 文档缺乏

很多公司都缺乏文档，当然我指的是领域文档，模型文档，接口文档，流程文档等。一方面是不够完善全面，另外一方面也是比较零散。从产品的角度来看他们产出的文档在一个地方，技术产出的文档在一个地方，另外也有部门墙的存在，所以导致文档其实没有发挥到最大的价值。

4.2 没有统一认知

没有统一的认知是领域需求落地的最大障碍之一，并不是每个公司每个部门都会认可领域驱动设计，尤其是领导层面，从领导层面来看他们可能并不太关心你用什么技术，怎么表达业务，怎么实现。所以如果需要达到一切需求从领域出发的效果可能需要自上而下的统一认知。

4.3 平台工具有限

另外一个限制是平台工具其实没有特别好用的，个人认为市面上几乎所有文档工具，技术平台都无法完整的满足企业软件开发需求，所以用领域的角度来管理需求变更的话需要从文档软件工具和效率平台工具去入手。比如在企业文档领域有QQ，微信，飞书，语雀，confluence等。产品文档工具蓝湖，processon等等。软件开发工具更多了，但是不同公司的规模其实选用的工具体系都不一样，我要表达的意思是这些文档产出的内容是否可以进行集成比如按项目角度去集成管理等等。

4.4 误区

昨天想这篇文章的内容时需要特别说明的一点是，一切需求从领域出发并不是非要按照领域驱动设计的那样去设计重构软件，有些简单的需求其实并不需要复杂的领域驱动设计架构来实现。所以核心的思想是希望将软件开发的思维从常规的方式转为从领域的角度去思考，构建基于业务领域的全景地图，每块内容都有完整的子地图及其发展演进过程。