DDD的思想的应用

我在上一篇说了下我在DDD实践过程中的一些想法。要长期实行DDD的话，领导的支持、人才的培养、领域专家的协助等，都是不可缺少的。很多情况下，我们都无法有这么好的条件。那是不是说，就没什么意义去学习领域驱动设计了呢。其实不然，且听我分析。

我本人兴趣广泛，喜欢东学一点，西学一点，偶尔捣鼓点小东西，自娱自乐下。但是对于一些枯燥的原理东西又不是特别感兴趣，这就导致了很多技术都是懂个皮毛，不深入。所以要往技术架构、技术专家发展就带来了一些困难，于是就想着往业务架构方向发展。只是网络上找了个遍，也很少介绍有关业务架构是能力怎么发展的书籍。后来想了想，业务专精的技术人员，因为受限于从事的行业业务，经验无法在其他行业通用。（这也是想往业务架构发展的技术人员一个要考虑的点。可能后续找工作会成问题。面试的一看是业务架构，偏向业务，要是和公司业务不符，可能直接PASS）。

后来接触了DDD后，了解了其背后的思想，才让我对业务分析这方面有了一定的进步。下面我就说说自己从DDD中学到的。

共识

业务专家不懂技术，技术不动业务，产品就作为了技术和专家中间的桥梁。可产品也有自身的问题，并非每一个产品都能对业务了如指掌，对技术的理解也止步于懂个大概。产品在传递一些信息和概念的时候，多少会参杂自己的理解，有的甚至是曲解。为此，DDD的做法是让专家、产品、技术一起参与项目，一起讨论。其中一个目的是能让项目成员都对业务中的一些定义、名词等达成共识。只有这样才能消除沟通带来的歧义，这也是对业务进一步分析的基础。

一个简单的例子，“订单”这个词不算陌生，但是在一个电商系统中出现“订单”字眼的地方很多，仓储系统、物流系统、交易系统、支付系统等。但是对于不同系统，具体应该是不同的领域，不同的上下文中，“订单”的概念是不同的，有些系统还会出现多种“订单”定义。比如，对于支付系统，就有支付订单和交易订单，而交易订单更多的只是一个与外部关联的值而已，支付订单才是它的业务核心。理清这些内容，建立统一语言，让团队对业务达成共识，这是DDD的思想之一。

从产品经理角度看业务

我很想说从领域专家的角度去看业务，不过这个确实很难做到的。

在了解DDD之前，我从没听过用户旅程、用户故事、事件风暴之类的名词，对产品经理如何分析业务也是一无所知。大部分开发基本都和我一样，对业务的理解都是来自现有代码和产品经理对业务的描述。代码本就是开发写的，而产品经理也不会把自己怎么分析业务的过程对开发说的很详细。这样，开发理解的业务就是很片面，很局限。当问及“某某接口是做什么的”这样的问题时，开发更多的回答就是，这个接口提供了什么样的功能，却无法回答上层的业务是如何的，接口在整个业务场景中的作用是什么。

要理解整个业务，就必须换个方式，换个角度去看业务。如果自己是产品经理，需要给开发讲解业务，能讲解清楚吗？如果自己从零开始分析、设计这款产品，又会怎么做？产品经理那些分析业务的方法自己是否可以学，可以用呢？只能说这样的转换是一个漫长过程，这找不到什么快速的学些方法，我自己还在慢慢摸索。也许有一天，不愿意做开发了，可以做一个懂技术的产品经理。

领域模型

开发不喜欢写文档，写出来的也不怎么靠谱。开发间通用的可能就是各种UML图和架构图这些。只是这些图都不能很好的反应业务，也是导致业务分析结果无法长时间留存和随业务发展而演进。

DDD需要产出领域模型，他是业务的抽象结合技术后的产物。他对开发更友好，虽然丢失了业务细节，但依然能很好反应业务。个人觉得，将领域模型作为整个迭代过程的中心，领域模型前是对业务需求的具体分析，确定领域模型后就是开发在它基础上做技术实现。领域模型也成为后续开发理解业务的一个起点。

从领域模型到代码模块

这个好像没啥好说的，到了实现这部，看的就是个人编码能力了。

DDD的学习，对技术的提升很有限，更多的是在提升对业务的分析能力。这个能力不局限于某一行业或领域，它是通用的。深入学习，以后怼产品、忽悠领导就全靠它了。