领域驱动设计DDD你也可以！| 第8期

摘要：践行者第8期，我们和易盛信息副总经理张廷利，易盛信息场外项目负责人李龙谱，一起畅聊了他们是如何从0开始进行DDD的！

践行者第8期，我们和易盛信息副总经理张廷利，易盛信息场外项目负责人李龙谱，一起畅聊了他们是如何从0开始进行DDD的！

一、领域驱动设计DDD

易盛信息副总经理张廷利和场外项目负责人李龙谱，在聊天中强调，DDD 是一个密码，是指导我们整个实践的一套理论，是一个很好的关于结构化思考的示例，能够把我们的业务都结构化，通过结构化的分层，方便我们进行上层业务的组装，上层业务的组装其实就是敏捷式的业务创新。

通过DDD，我们会在一开始把需求描述清楚，按照业务流程把这些规则描述清楚，通过我们的技术构造，让系统运转起来，这就形成了一个通路。最终应该是我们要达到的目的，应该是支持业务人员自由创作的这么一个自由创作。

总而言之，DDD其实这整个是一个结构化思维，它一方面是把代码结构化了，另一方面是把业务也结构化了。结构化的结果就是把所有的这些东西，拆分成类似乐高一样的模块，这样我们业务人员就像玩乐高积木一样，可以用它去拼一个轮船、拼一个汽车。我业务人员可以随便拼，并且模块之间也是相对稳定的，每一个模块既可以被业务人员理解，也可以被研发人员理解。这样我们就在业务和研发之间建立一个非常好的桥梁，让工作变得很简单。

二、直播问答实录

1.你们在推敏捷吗？DDD和敏捷应如何结合？

其实没有刻意地去做敏捷，但我们交付的版本速度比较敏捷，基本一两周交付一个版本。实际上，当我们把业务模型想清楚后，对版本规划能更清晰，便可以知道短期内我们需要做什么事情，需要如何发版本、如何集成以及如何测试……

我们没有专门的敏捷教练，除DDD外，我们也很关注CI、CD，实现快速集成、快速部署、快速测试。虽然我们没有固定的迭代周期，但也差不多一两周一个版本发布，包括测试人员也是在形成业务架构模型的时候参与进来的。

2.DDD概念和微服务集群有什么区别？

DDD这套理论能够帮助划分微服务的边界。它们不是能够进行比较的概念，DDD是一种手段。

3.有没有找亚马逊的顾问现场一起做呢？

没有的。不过实践DDD，大家可以看看张逸老师的书，书里介绍得很清楚，并且给出的是一套如何实践的方法。非常推荐大家看一看。

4.领域驱动设计的目的是什么？

这个问题的答案在Eric Evans书的副标题中能得到解答，它叫《软件核心复杂性应对之道》。软件核心复杂性其实指的是业务复杂性，包括业务变动引起的难以预测的复杂性。

5.谁来拆分业务，是需求分析人员吗？

是业务和技术负责人一起来拆。

6.你们做事件风暴工作坊之类的实践吗？

之前尝试过，但后来发现这类实践其实是需求分析的工具，它可能更开放一点，需要有业务专家的参与，包括技术、开发、测试等等。

我们可以用其他的手段代替这类实践，如传统的需求分析方法，我们可以从业务开始到结束的时间线出发，把整个业务线梳理清楚，逐渐在脑海中构建出一个模型，接着通过这一模型不断去推演所有的业务场景。有了业务模型后，才能反映到文档上、与别人交流，并最终反映到代码上。对于初学者来说，还是可以体验下事件风暴的，应该会有一些感触。

7.DDD就是业务架构与技术架构相互映射对应统一的过程吗？

在DDD中，业务模型和技术模型是一个模型。同时，这是DDD中的一个关键点，并非全部。

8.需要让业务、技术人员都了解DDD模型，应先在业务的角度考虑，是这样吗？

让业务、技术人员都了解DDD模型是一个很关键的部分。而站在什么角度考虑这一问题，其实整体业务架构还是会偏业务多一些，同时也会从一些技术实现的角度进行考虑。这里要注意的是，从技术角度考虑并不是考虑到代码的维度，而是从技术角度看能否实现。因为整体业务模型其实还是业务，和技术细节没有关系。

9.能推荐一本书吗？

大家可以看整洁代码架构方面的书，还可以看付晓岩老师写的关于银行数字化转型、企业架构、聚合架构的书。刚才说的映射过程，《聚合架构》里也已经说明了，比如如何分析业务过程，如何把公共组件抽出来等等。书中提到DDD是一种做领域抽象的方法，大家可以去看一下。

其实很多书都是讲原则理论，我们可以先了解这些书的内容，最终还是需要先行动，在过程中找到解决方案。

10.好的领域模型带来的价值是巨大的，那用什么方法才能得到好的领域模型呢？

Evans大概 2014 年的时候，画了一张叫做“Model Exploration Whirlpool”的图，这是由三个圈组成的图：第一个圈指业务场景（通过用户故事表达），第二个圈指领域模型，第三个圈指代码。

（图源：https://www.domainlanguage.com/ddd/whirlpool）

Evans用这张图来解释我们应如何构建模型。当我们拿到一个新的需求，首先要把业务场景表达出来，接着看我们的模型是否能支撑业务场景。如果能支撑那么模型就是合适的，如果不能支撑就需要进行调整，调整后再落实到代码层面。

其实这就像一个洗衣机（惠而浦洗衣机），把这三个东西在里面不停地搅和，慢慢找到更适合的模型。一个好的模型能够像洗衣机一样，通过持续不断地动态过程反复提炼出来。

11.你们做度量吗？有已梳理好的研发流程吗？

我们的流程在 CI、CD 层面已经工具化、自动化了，但在度量层面上还需要再加强。今年准备趁着DevOps优化机会，在度量方面再加强一下。我认为度量能够帮助我们做管理，但是不能指望靠度量管理。

关于度量，有一些比较有挑战性的问题，如果不度量的话，领导怎么知道谁在偷懒？这些其实可以靠生产指标来判断，比如需求响应速度、生产的故障率等等。其实基于DDD的很多开发是固定的，我更建议看到实效后，再开始度量。因为度量有成本，并且度量一般都是和自己比，不应该是团队之间比。最好的方式是先让自己的工作方法成熟定型，然后通过度量来进行不断地优化。

12.有没有好的原子服务模块切割好的方法或者思路？

首先，经验很重要，你需要对这个领域有一定的认识，另外要对现成的需求分析，包括事件风暴这些方法论。并且你需要不断地反复地去尝试，去思考这个事情。

原子服务其实又回到结构化思考了，结构化思考里有个MECE原则，就是关于相对独立，穷举的概念。我们可以去找到这种原子服务模块，但最后进行组装后，他还需要彼此聚合，因为划分的很细时，原子模块是不好用的，它必须得结合成一系列的概念。

DDD里会有隐喻的概念，比如在极限编程里有提出隐喻的方法，可以将它用在模型上，去诠释那些稍微大一些的概念，在这个层面上讲一个自成体系的模块，它就是一个原子服务，但这也是千人千面的。你可以根据你自己的理解去做，中间是有弹性的，并不是有完整的非黑即白的结果，它是根据你的需要来进行组合。

另外一个方面就是这种原子服务组装出来之后，我们可能还没有做微服务，但是我们的应用内部已经做了隔离切分，就像DDD里讲大泥球反模式，虽然在一个大进程里，我们把它切分的更条理化，它可能和这种微服务，没有强关联的关系。只是你去治理你的知识结构，由知识结构逐渐衍生出来一些系统和业务规则，就是业务层上的一些组装。

如果说到好的经验和方法，我推荐前面提到的“三个圈”方法，就这三个圈不停地在搅和，你就慢慢地能找到一些切分的方法，这需要自己心里有把尺子，自己觉得合适就好。它没有一个统一固定的标准。