领域驱动设计part1

以下为现场演讲内容

王立：先做一个自我介绍，我是来自姚明众创，我目前是姚明众创的技术负责人，曾经在多家上市公司担任架构师和技术经理，包括阿里巴巴，今天很高兴能跟大家来分享领域驱动设计。领域驱动设计大家应该都听说过，你们在实际项目当中有用过的吗？能不能举个手？没有。确实说领域驱动开发是很有难度的，领域驱动开发我接触的时间比较早，10年前就接触。今天我把我这段时间从事领域驱动开发的心得跟大家做一个分享。

为什么我们要来用领域驱动这个概念来做开发呢？这张图大家很熟，最初用户可能是要做这样的东西，做这样的秋千，而产品经理理解是这样的，而到了设计师是理解层这样，而程序员做成这样的，而外部的商业部门宣传是这样子，而我们测试人员拿到的是这个样子，最后实施的是这个样子，到客户的手里是这个样子的。这就是典型的需求问题。为什么会造成这样的问题，其中很重要的一个原因就是沟通不到位。

为什么会沟通不到位？Booch曾经说过一句话：科学的一个普遍问题是必须对被观测的对象和情况，建立一种有意义的分类方法，以便人们理解这些观测结果，也有助于科学理论的持续发展。因为我们没有去表达它，去理解他，所以说我们每次信息传递和理解的时候就会出现歧义。

如果我们没有数学表达式的话，很难想象数学领域的发展。正是因为有数学的表达式，才促进了数学的思考和发展，不仅仅是沟通的问题，而是一个理解和发展的问题。那么面对这么复杂的业务，用什么样的表示法去沟通、去理解、去发展？我们没有。所以这个时候就必须要引用一种表示法，这个表示法就是以一种叫做领域语言模型的东西。

界面描述不等于业务需求，因为业务需求涉及内部业务对象的各种状态组合与彼此动态的逻辑关系。你看到的产品界面部分都是冰上露出水面的部分，水下的部分看不见，所以说我们需要一种UML+业务词典的方式，用这种标准的方式来表述、理解和思考它，这里面包括了流程图、协作图、状态图、活动图等。领域模型语言是领域驱动开发的基础，那什么叫领域驱动开发？

先看什么是领域，领域就是业务领域，我见过很多伙伴们在分析业务的时候，最常用的就是脑图，从一个问题领域的主题开始然后一层层分解——业务是什么？有哪些概念和关系？有哪些状态与规则？有哪些场景？有哪些流程等等，这些都是领域的问题，只要是同一个问题领域，就存在相似性。比如大家发现银行好象业务都差不多，你研究多了，你就成了银行专家，所以专业领域是很值得探索的。

那为什么我们要做领域建模？业务的表现是各种各样，A银行和B银行的业务看上去是不一样，但是内在的本质是一样的。再比如财务，那个时候最早没有财务这个软件出现的时候，可能大家每一家公司在财务问题上都有自己的一套实现方式，但是最终有一个财务软件出来，说所有的这些问题只要一种模式去解决它，能够通用。那为什么能通用？财务软件解决了一个问题，就是探索到需求背后不变的本质，本质一直都是不变的，而只是外部应用的环境在变，但财务软件始终适用，如果你对本质的理解是错误，就像你把地球理解成平，不是圆的，你也能解释昼夜交替的现象，但是，你就很难解释其它更复杂的天象，同理，对业务本质的提取如果是错的，软件将来就很难满足各种合理的需求变化，这是我们应对需求变更如此痛苦的重要原因之一，我们需要用科学的方法来建模和提取本质，也就是用UML来设计与表达业务领域的概念、关联关系与内在的规律。

我面试过一些开发人员，包括架构师，我问他们怎么思考架构设计？他们说用了ssh架构，或者ssm架构，其实这种架构跟业务没有关系，每家公司都一样，根本不是一个应用架构特有的价值所在，对一个企业来说，要有竞争力的话，就是要获得那些与业务本质有关的核心资产，使得你可以以最低的成本随需而变，超越你的对手，你的优势就体现在这里，所以，提取本质才是我们的核心。

那什么叫驱动？从领域到领域模型到设计环环相扣，我们始终围绕核心模型进行分析设计，把语言、代码、模型三者紧密绑定（不同于传统分析、设计、实现三个是完全脱节），使得软件既能满足当前的需求，也能支持未来的扩展，让领域模型驱动一切，这就叫驱动。

领域驱动设计主要是包含了三个部分：一个是领域分析，分析你所看到的业务，但是看到的业务不代表内在本质。第二是领域设计，定义业务的内在结构——本质模型。第三是实现，就是把本质模型映射到系统。

第一步，领域分析，就是要理解领域。这其中我们需要三种人员:开发人员、领域专家和最终用户，首先需要的是领域专家，它对这个领域特别的熟。但是领域专家的思维不像我们程序员这么严谨，所以需要开发人员的参与，而且领域专家的用户体验也不如终端用户那么深刻，所以需要三者的共同配合。

有了这三者的合作，然后我们接下来要去怎么去理解业务，这个时候要有方法，这个方法首先是拆分领域。

关于领域拆分很重要的概念叫做Bounded  CONTEXT，就是限界上下文，比如说商品交易就是一个有界限的应用场景，就是一个限界上下文，还有比如说库存管理也是，财务也是，等等。这都是属于具体的业务环境，也就是界限上下文，同一个用户，你在不同业务环境扮演的角色是不同的，就有了不同的角色命名，同一个事物，在不同的业务场所，业务概念也不尽相同，所以说，先有限界上下文，才有业务对象的概念命名，才有业务词汇的标准统一，你才能够精确的去表达你的业务的概念，然后记录到词典里，这个时候交流才没有歧义。所以上下文是模型有意义的前提。

有了对上下文理解之后，为了更好地理解业务的主次关系，需要对领域进行分类

比如说电子商务的网站称之为是一个大的领域，这个时候商品模块就是一个子领域，并且是核心领域，离开它，其它的领域就没有意义了，会员服务也是一个子领域，身份验证也是一个子领域，这些子领域我们把它称作为支撑领域，再有：身份验证，是通用子领域，因为所有子领域都会依赖和使用到它，所以叫做通用子领域。

然后，针对每个子域，我们进一步思考这几个问题。重点是梳理出我们要什么功能，而不是思考如何实现这些功能，如何实现是软件设计人员的职责。