数字化时代下的 DDD 新形式

在设计领域，DDD带来的变化是什么？在微服务方面，DDD 又带来哪些新思潮？目前实践 DDD 最大的困难是什么？11 月 30 日，在由 ThoughtWorks 举办的领域驱动设计峰会DDD-China 2019上，InfoQ 记者带着这些问题对 ThoughtWorks 创新设计总监肖然进行了采访。

DDD——设计团队的新视角

十年前，设计领域提出了一个跟 DDD 类似的方法，名叫 Design Thinking。Design Thinking 某种程度上跟 DDD 有异曲同工之妙。

一般而言，设计思维强调两点：

• 第一，设计一定是靠跨角色的协作才能碰撞出来的，因为世界上充满了不确定性，这跟 DDD 要求业务人员和技术人员统一语言继而协作的道理是一样的。

• 第二，设计思维在对问题和解决方案的认知上面，跟 DDD 的想法也是一样的。从设计的角度看，更重要的一点是怎么认知问题。

DDD 的思想要求看待问题更加注重上下文，产生的不同解决方案是源于对同一个问题的不同视角。设计团队接受 DDD 的概念本身没有什么难度，因为其工作性质就是如此。在数字化时代以前，技术和业务的职责划分很清楚，业务写需求，技术写实现。但随着业务需求的频繁变动，行业里提出了敏捷开发、产品迭代。

在数字化时代，很多数字产品、数字服务必须要持续追求更好的业务体验，回到对用户的关注上。这个时候设计团队需要被植入到整个产品开发过程中去，所以出现了与之前技术和业务协作同样的问题，因此，DDD 的概念在设计领域也开始被人们所关注。

设计领域本身产生了很多基于协作的方法和实践，设计上可以学习 DDD 的地方是统一语言。DDD 最具参考价值的地方在于其尝试建立一套元模型，这套元模型能够为业务、技术、甚至设计人员所理解。在这一点上，如果能够在持续改进的过程中引入 DDD 的思想建立统一语言，对设计本身非常有帮助。

肖然提出“设计域”概念的背景，在于数字化时代的设计，需要反复尝试和试错，在问题和解决方案之间来回摸索，如果没有让设计、业务和技术人员共同认知到这是一种常态，协作就会出问题。认识到在工作中存在这样的“模糊地带”，处理方式上就应该避免一个问题点一个解决方案，而是多点发散，多点尝试，最后找到最佳方案去规模化实现。

设计域的未来

数字化时代以前，设计实施后修改成本很高，比如智能手机的设计建模，样机做出来后再修改的成本超过数十万元。但在数字化时代，设计的成本大大降低。举个例子，网页上的 A/B Testing，某种意义上既是问题又是解决方案，原因在于设计者也不清楚哪种方案更好，所以选择让用户去做投票，收集到真正的使用数据，进而再决定合理的解决方案。

设计域目前存在的挑战在于整个团队如何切换固有思维，对于问题和解决方案的定义并没有必要那么明确。举例而言，肖然在演讲中提到的人类移民火星这件事情，如果把其当做一个问题，解决方案可能是让火箭更廉价，怎样重复使用火箭。换一个角度，如果说人类移民火星只是解决方案，问题就变成了如何让人类成为多星球的生物。

业务思考的人、设计思考的人和技术思考的人，他们思考的方式不一样，最后的碰撞就是大家对问题和解决方案本身的划分就不一样，到了一定的时候，特别是面临高度不确定性，为什么一定要划分呢？为什么不能大家都认可处于这样一个模糊状态，我们要做的事情就是多点尝试，然后得到多样反馈，最后能够更快迭代升级解决方案。

DDD 跟 Design Thinking 很像，但它更偏重于技术人员。从技术的视角，要跟业务建立统一语言，同样也要跟设计建立，否则仅仅依靠可视化的高保真图去构建数字化产品和服务是无法应对现实中的不确定性的。肖然表示自己始终在尝试将 Design Thinking 和 DDD 进行融合，因为让设计人员真正理解 DDD 的抽象概念和方法论还比较难。但很多 DDD 实践，不少设计人员发现与 Design Thinking 的实践很像，从而能够产生更多的共情。

肖然认为，目前的业务和科技已经融合的差不多了，设计将会在未来融入到产品迭代的全周期中。现在很多的所谓“标准事件”，实际是设计做完，技术实现。设计域未来会形成跨角色协作的公式，如何建立一套统一语言是当务之急，但是不是一定要 DDD 的模型却未必。

DDD 与微服务

有人说，托微服务的福，DDD 的思想重新走向了流行。

肖然认为，这个问题可以反过来说，目前微服务的划分方法里全球共识的就是 DDD，但 DDD 的核心思想并不仅仅局限于微服务本身，因为微服务是一种架构风格，而 DDD 是一种思想。微服务定义的九大核心特质，跟 DDD 的原则是完全一致的，这在某种程度上也是业界愿意在微服务上下文中采用 DDD 方法和实践的原因。

另一方面，这也造成了一定的问题。举例而言，在拆微服务的方法上，比如说数据导向的应用，很难用现在流行的 DDD 方法来实践。但如果不用 DDD 的方式拆，用什么拆又成了新问题。现在业界还是很缺乏相关的实践经验。在微服务的设计，特别是在服务划分上，即使在 DDD 思想的指导下，也还是有很多方法需要持续沉淀和提炼。

作为最近两年的技术热点，Service Mesh正在尝试解决微服务整个生命周期管理中运营和治理高成本的问题，它会进一步推动微服务架构的发展。至于它会不会影响到接下来的微服务划分，肖然认为有可能。比如在 DDD 的限界上下文划分中，如果你据此划分微服务，考虑到安全、信息传输等约束时，Service Mesh 作为一种微服务架构的落地实例化，很可能让你在划分的时候有更多的灵活度。但也因为 Service Mesh 本身还不成熟，国内也就几家贡献者，工业应用案例不多，所以未来还不好说。

DDD：火爆与困局并存

DDD 理论最早提出在 2004 年，此后的十余年时间里一直不温不火，直到最近两年才得到了越来越多的关注度，原因何在？

肖然认为，从全球看主要原因就是欧美企业的 IT 化进程已经走完，进入了数字化时代。在这个过程中发现软件服务的领域差别特别大，由此带来的不同领域的软件开发难度也有很大不同。而 DDD 思想的核心在于建立统一语言所带来的上下文一致，这对解决不同背景人员理解业务问题上下文不一致的挑战非常有帮助。这是 DDD 在全球范围火起来的原因。

在中国火起来的一个核心因素就是中台概念。中国企业在过去的两年间频繁提及上云，但在上云过程中却发现很困难，因为软件应用架构过于笨重。上云终归是绕不过去的趋势，中国企业如何上云？就是要调整原有架构，使其适应云时代的要求。如何调整架构？DDD 的思想比较合适，因此 DDD 在中国流行的原因不同于欧美，主要在于上云要求的架构调整痛点。

DDD 可以理解成一个架构的设计思想，通过 DDD 指导中国企业去做云时代的架构建设。

目前 DDD 思想在国内虽然渐趋流行，但同样面临着诸多问题。现阶段最大的障碍，跟当年敏捷开发面临的障碍是一样的，即如何调整组织架构。

过去业界提到敏捷开发，都说对个体的要求太高，但实际上并不是。表面上看敏捷对开发人员的技能要求高，实际上是因为敏捷开发要求调整组织架构，很多人不愿意动，因此业务和技术协作上的问题很难解决。

DDD 面临的困境同样如此。在过去，技术这条线的划分可能是开发一部、开发二部，业务这条线的划分可能是业务一线、业务二线。但 DDD 的划分理念是从业务角度划分成领域，领域再划成服务，落地的时候采用微服务架构，以前的划分方式完全适配不了。所以直接造成 DDD 落地难的阻碍也是组织结构。具体表现就是协作不起来，各条线相互甩锅，领导抱怨团队人员能力不够。

肖然认为，如果企业确定要走 DDD 指引的架构方式，那么其组织结构就一定要按照领域划分。不见得未来所有企业最后的 IT、数字化平台就是领域化的，但如果确定了走领域驱动，那就一定要调整组织架构以适配 DDD 思想，如果不走，那就没必要为了 DDD 而 DDD。

软件开发没有银弹，中台不是，DDD 也不是。唯一有的，是不断拥抱变化的业务与场景，让软件架构从变化中持续生长开来。