DDD(Domain-Driven Design 领域驱动设计) 与产品设计

DDD (Domain-Driven Design 领域驱动设计) 或许也叫 Dream-Driven Design，某度说这是一种程序的设计思想，程序员使用诸如聚合根，值对象，六边形架构，CQRS(命令和查询职责分离)，事件驱动等等概念，在领域专家的指引下构造代码。据说这种情况下写出的代码具备领域划分明确，响应需求变更快等特点。

但在目前看起来，大部分情况下似乎都是用来吹逼的东西，概念虚无缥缈，实践困难重重。领域驱动设计到底有啥用呢？真的只能是吹逼的东西么？

缘起

最近公司业务需要，我从一个只写java的码农逐渐转变成一个写golang的码农，然后呢，又从一个写golang的码农开始接手产品的活计。

以前从Java搞到Go还在同一领域内，现在做产品…感觉连物种都换了。

故事的起因是公司需要做一款服务于运维和研发的技术属性比较强的工具类产品，然而产品团队很难理解其中的技术概念，搞了半天搞出一个四不像的东西出来。

公司终于发现这种玩意靠产品团队基本不太现实，就从研发中挑了一个水平最菜的出来干产品算了，估计是想着反正水平不行还不如利用一下剩余价值，也没什么损失。所以很不幸，中标了…

尝试

刚开始接手产品设计的时候我很不适应。研发需要考虑的是这个需求如何实现，如何优雅的实现，如何实现的更快方便增加摸鱼的时间。这个过程有点像是搬砖，脑子里面只需要想着这块砖怎么垒上去，怎么不让它掉下来，然后付出体力就可以了。

而产品需要考虑的是需求在哪，需求怎么转换成可以被实现的产品，这个做出来的产品有没有价值，能不能卖出去。这个过程有点像是面对一片空地，空地上能长出什么得靠自己去想象。

由于缺乏想象力，我开始寻找一些技术属性比较强的工具类产品，尝试着把它们安装起来，看看这些产品有什么功能，它想表达些什么意思，它是怎么实现的。在这个过程中，我发现了一个很有趣的事情，有2款功能相似的同类型产品，它们居然在安装体积，服务数量上面表现出了巨大的区别。按理说大家功能相似，那么技术服务产品，肯定写出来的东西大差不差才对。结果却是其中一个产品服务数量居然是另一个的3-4倍之多！！！

竞品的对比

我先介绍一下背景，它们都是属于云计算领域的产品，是基于k8s的pass平台，主要作用是为云上应用提供管理作用的，属于功能相似的竞品。

首先是产品1号，1号运行方式是跑起来一个docker容器作为控制台。容器起来之后需要对接 Kubernetes 集群，将config文件给到控制台，大约在集群里面安装15个左右的容器就可以完成对集群的控制，我是用kind搭建的集群，基本上单机就可以玩起来。

接下来是产品2号，这个产品的安装包我是费了好些力气才拿到的，拿到一看，安装包足足74个G！一看安装文档，一共70多个服务，最低要求14台机器，推荐安装27台虚拟机！！！

这是什么航空母舰，差点当场给我吓傻了。

没办法，毕竟产品还是要调研的，总得装个看看，我申请了14台机器，按照最小的规模安装，2号产品的控制台是在集群里面的，中间件呢大多在虚拟机上面，控制台得单享一整个集群，5、6台机器装中间件，业务集群另装…

费了千辛万苦，终于将2款产品全部安装完毕。在经过了一段时间的体验之后，我发现在主要功能上2款产品是差不多一样的逻辑和思路，但在实际把玩的过程中，1号的稳定性明显优于2号，很多时候2号在部署一个应用10分钟起不来，成功率大概只有3成，1号的应用基本都在2~3分钟起来，而且成功率在6成左右。而且2号过一段时间就会出现故障，产品本身很不稳定，1号就稳定的多，基本没出过什么故障。

领域驱动设计，驱动的是什么设计？

这是到底为什么呢？2号费了那么大的劲，做了一个要求27台集群才能部署起来的航空母舰，在主体功能上和1号大差不差，稳定性上相差这么大。是2号产品的公司研发能力不行么？

怀着这样的疑问，我大概的看了一下这2款产品的服务，想去了解他们当时写这段代码的想法，终于，我发现了一些问题所在。

2号产品的服务写的很多，而且很乱，比如在k8s上面部署一个应用的功能，2号产品单从名称上看就有7、8个服务与这个业务相关，连带着的中间件，上下游服务都不知道有多少。1号产品的服务看起来就很精炼，基本上从名称都可以看出哪个服务主管哪一块业务，中间很少交差，这个服务设计的界限分明，让人看着就心旷神怡。

等等，界限分明…这不就是领域驱动设计么！！！

我似乎有点明白领域驱动设计了，技术是服务于产品的，产品是服务于业务的，如果从纯业务的角度去看，那么一件一件的需求都可以被划出不同的领域。领域驱动的似乎是产品设计！

比如有一个应用部署在k8s里面的需求，部署是一个动作，k8s是一个产品，那么我们就可以提取出一个领域—k8s。按照k8s的数据驱动设计理念，部署一个应用就是创建一个资源，我们需要做一个专门针对k8s资源的增删改查服务，而且这个服务应该依赖k8s，作用范围也得在k8s的范围内，只有将自己约束住，与其他业务互不侵犯，才做的好一个高质量的服务。

以前我太过于注意到聚合根，值对象，六边形架构，CQRS(命令和查询职责分离)，事件驱动等等研发的概念，直到现在需要用产品的视角去看问题的时候才有些理解书上对于战略和战术的划分。

业务决定领域，领域决定架构，所以产品架构决定技术架构，一个好的产品架构，一个能够将业务划分的十分清晰的产品架构，对整个技术架构的支撑是能起决定性作用的。

如果一个产品在设计时是处于一片混沌状态，分不清楚核心价值在哪，想一出做一出，往往到了一段时间之后就会像2号产品一样，为了实现某个业务需求，想尽各种骚办法，以增强体量和复杂度为代价去勉力支持，这种玩法不仅会做的很慢，还会导致体量越来越大，整个系统越来越不稳定。到时候产品各种毛病，是由于研发不够努力么？确实有可能，但是我发现研发作为执行者，出问题大多都是单点故障，产品如果没想明白，就会出现一个整体性垮掉的情况，就算再牛的研发都无法从技术上拯救，慢慢的沦为屎山项目。

结尾

之后，我花了大量的时间去思考我们这款产品的价值，每天都在问自己，这个产品到底有啥卵用，在没想清楚之前哪怕让研发都在摸鱼也在所不惜。

最终在划掉大量的时间之后我们找到了方向，恐怖的是刚开始的研发速度就非常快，还越来越快，往往一个迭代2周时间，结果3-4天就砍瓜切菜般的解决了，剩下的时间要么用来摸鱼，要么用来做下一个迭代的预研。甚至到后面瓶颈全都在产品设计上，画原型图1周，写代码2天，画图还没写的快，就离谱…

在我的理解中，领域驱动设计是用领域的思维来辅助产品设计，良好的产品设计决定了技术不会走弯路。至于聚合根，值对象，六边形架构，CQRS(命令和查询职责分离)，事件驱动等等战术上的东西，这个其实并不太重要，毕竟只要服务职责划分清楚，代码用mvc结构还是事件驱动结构都决定不了太多的东西，就算完全摆烂，破坏力也有限。

写在最后: 在思考产品时，我写了很多文档(虽然很烂)，这些文档在后续研发过程中都发挥了十分重要的作用。身边一些团队在践行所谓的敏捷开发模式，以敏捷开发要少用瀑布模型那种文档为由啥文档也没有，结果呢到了后面谁也不知道这个功能是怎么做的，敏捷开发真的要少写文档么？这是个值得去想的问题…