一、背景

1.1 背景

之前业余项目耽误了些时间，关于DDD方面的内容暂时搁置了，所以一个比较大的主题就暂时先搁置了，现在终于有时间来写一写令人比较兴奋的部分–DDD落地的思考。关于这个主题，其实有很多新的东西我希望跟大家分享一下，也是我学习DDD遇到的一些问题的思考，另外呢就是Eric的模式里为什么有时候用到现实代码里或者跟微服务结合之后显得有点困难，比如代码量增多，读写不容易分离等等问题。其他方面就是关于组织，团队领域方面的内容，为什么战术战略与组织结合就显得水土不服。结合最近跟不同大佬的聊天内容和社区对DDD的讨论趋势，越发觉得DDD需要有一些新的东西可以添进去，因为目前看eric提到的一些模式可能有些时候已经不够用了，或者不足以解释发现的新问题了。当然我不是制造噱头，弄个DDD2.0什么的。最终还是希望大家通过本系列去深入了解和实践DDD，遇到问题和相关场景可以从本系列文章中找到一些答案。

1.2 文章概述

本篇文章将总体上给大家讲述软件开发在不同领域蓬勃发展的趋势和内容，新时代的软件研发技术体系和新领域的细分内容发展都标志着还有很广阔的空间让DDD去施展拳脚。

二、数字化转型

2.1 业务和组织模型

说到数字化转型，需要说的一些前提就是业务和组织模型的数字化，包括业务的关联，业务趋势，业务需要的各种业务系统和中台系统，面对不同时期不同趋势能优先从业务和组织上去考虑更深层次的问题。所以从模型上看，如何更灵活的构建软件系统，更快捷的应对市场变化是业务和组织驱动的动力。

2.2 统计与量化

说到统计和量化其实个人认为是一个成本比较高的投入，比如广告投放，大数据分析需要的一些资源，对接第三方需要的成本等等，但是却又不得不做，因为基于数据的数据有时候是能看出一些业务价值的，所以基于数据建模，找到数据里的数据也是非常重要的，目前看大多数企业对自身的各方面的数据统计都不够全面，相对零散。

2.3 大规模立体化

经过前面两小节的叙述，数字化转型个人看是相对困难的事情，需要的数字化人才，相关的软件等都比较多，能达到大规模立体化则显得相对理想化。

三、工程架构

3.1 基础设施架构

现在的软件复杂度比之前的复杂很多，由于分布式，微服务和大数据等技术的深入应用，对基础设施架构的和基础设施软件的要求也更多，云原生的基础设施软件也有很多很多了。那么回过头来看DDD，个人感觉DDD与架构来说虽然没有多大关系，但是DDD所倡导的一些战术战略理念仍然可以辅助架构层面做一些指导工作。

3.2 后端工程架构

就目前看后端工程架构的落地还是比较多的，也比较丰富，所以对后端来说DDD的落地会相对容易一点，但是不可忽略的是一旦到了战略层面DDD就可以帮助更好的规划业务和技术进行协调。所以未来不管后端架构怎么变，DDD作为业务内核是不变的，围绕业务模型做延伸的思路总不会错。

3.3 前端工程架构

这几年前端也有很大发展，基于前端架构的体系也已经形成了。另外有些大佬在前端应用了一些DDD的思想，这是一个很不错的想法。前端组件化相关的方向我也跟踪了一些时间，发现原理和理论基础都差不多。所以DDD的一些模式还是值得学习的。如下是一位大佬写前端相关的文章，感觉不错，分享下:https://componentless.com/

四、云原生

4.1 微服务

自从微服务流行之后，感觉DDD也火起来了。DDD与微服务的一些战略思想是相通的，这就促使DDD也需要一些发展来跟上技术趋势和业务场景的趋势。以不变应万变可能不是特别适合了。

4.2 分布式

在分布式领域相关的DDD应用可能不是特别多，但是一个比较特别的地方就是需要对分布式场景进行建模，梳理模型之间的关联，包括分布式下的不同上下文如何区别对待，也就是说在技术因素太多的情况下如何用DDD的思想去各个击破也是一种思路。

4.3 大数据

说到大数据其实就是DDD目前看缺失发展比较多的一个方面了，为什么呢，因为大数据是汇总不同领域上下文数据的，说白了就是跨聚合，在我们的业务代码里几乎很少看到大数据相关的代码内容，但是并不代表不存在，大数据如何跟当前的业务系统结合同步发展其实也比较重要。一个比较典型的案例就是搜索，搜索基本是跨聚合的，那么在业务代码里构建搜索相关的元数据(比如索引)可能不太适合，唯一能做的就是业务系统调用搜索客户端来做一些数据同步和查询，查询可能就涉及到跨层调用等等。另外一个场景就是数仓，存取数据已经按聚合角度来构建了，那么新的聚合模型应该怎么设计更符合业务需要，如何让数仓里的数据解决业务系统里的大量查询也是一个重要应用场景。

五、低代码

这里举一个最近两年比较火的领域–低代码领域。低代码行业也发展了很多年了，但是仍然没有到真正的天花板，虽然做低代码会很容易到天花板。我们仍然可以从这个领域窥探出一些DDD相关的内容。

5.1 垂直领域

从垂直领域看用两个维度来说一下：

  1. 技术

    1.前端低代码 2.后端低代码 3.拖拉拽(可视化) 4.移动端低代码 总体来说可以分为以上四类，如果一个低代码平台能覆盖以上4类那确实足够到了低代码本身的天花板了，但是事实上远不止于此，很多低代码企业也结合了更多可重用组件，和云基础设施来做文章，从需求到软件发布一体化。那么此时就不再是低代码了，所以对低代码的内核来看如何保障本身不受影响，边界清晰，不同模型可以相互适配都是架构师和设计师的挑战。

  2. 业务

从业务的角度来看，就是流程方面，表单方面，hr,财务，绩效，审批，调查问卷，数据报表等都是低代码可以发挥优势的地方，那么以业务的角度来看低代码其实就是低代码+特定行业领域的一个特定方案，本身可能就不够低代码的通用性，而是考虑业务的通用性。这样的话如何从业务的角度出发让模型更灵活更容易用低代码的方式扩展也是一个挑战。

5.2 SAAS服务

SAAS服务也是一个比较特别的领域，但是在中国的SAAS服务跟国外还是有一些差距，不管怎么样，SAAS场景本身就是个性化与通用性相互矛盾和统一的产物，如何构建SAAS服务的护城河则需要更多的创新能力，也需要让软件跑起来才能获取更多用户。所以从软件本身来说快才是占领市场的王道。当然快也不是说不考虑质量，多次迭代多反馈才更符合软件研发的特征。

5.3 DSL

经过上面的铺垫终于说到DSL了，其实很多人已经意识到了DSL在低代码领域其实是比较合适的一个方案，类似于组件化的积木搭建，用DSL可以更好的提炼核心模型和业务语意，在使用方面也不会显得特别复杂，那么DSL在DDD里也是比较重要的一种模式，只是没有讲的太细，但是方法论和实践已经有人去完善和落地了。

六、其他新领域

目前看其他新领域也可以运用一些DDD的思想去解决问题，比如serverless,硬件和嵌入式，也有一些大佬在算法等场景下进行少量运用，所以未来在新领域进行探索的时候运用DDD的一些方法论可以更好的抓住核心矛盾。

七、新环境

7.1 新冠疫情

新冠疫情影响了全球经济的发展，每个人都受到了不少的影响，不同的企业采用了不同的策略来应对疫情，居家办公成为主流，随着疫情的持续，很多企业也开始裁员，所以将迎来更激烈的竞争和内卷。

7.2 远程办公&混合用工

远程办公和居家办公的策略目前看国内的企业还是很少采用这种方式的，实际上个人觉得如果你的工作性质就是坐在电脑面前或者可以把工作带回家是可以远程办公的。对于一些重生产型企业，类似于采矿行业也可以进行封闭管理。也就是说如无必要，居家办公。另外一方面混合用工也出现在了一些新零售的行业里面，这个场景如何加入当前的人员和企业用工流程中也需要一些新的方案。

7.3 线上化办公工具需求

居家办公与在公司办公还是有很多区别的，比如居家办公的沟通问题，效率问题，重大项目跨团队协调问题等。就目前看来我们有很多线上的办公工具了，但是可能还不太够，比如有些企业就会监控员工的工作时间，防止摸鱼。企业不太信任员工在居家环境中能创造类似同等的价值。也就是说如果可以丰富下线上办公的工具也许可以解决这个问题。比如对工作任务的线上化管理，线上站会，日报等情况来描绘工作产出。

八、DDD火了

之前有人统计DDD的搜索词趋势，最近两年确实火了，但是很多人仍然没有太入门，又或者觉得自己资历高经验多看不起DDD，但是不管怎么样DDD既然火了肯定有其道理，从理论到实践确实需要花费一定的时间，为什么DDD比较难学，一方面没有固定模式，另外一方面概念太多，没有主次，最后可能就是没有场景，大多数人没有遇到合适的场景去学DDD。所以在工作中还是要主动揣摩历练DDD的不同模式才能更快的运用这门方法。