领域驱动设计，让程序员心中有码(三）

　　“正如西方古典哲学在现代社会逐渐式微，成为少数内心丰满者们填充自己精神世界的宝贵食物，UML也这样；互联网技术飞速发展的今天，各类软件设计思想层出不穷，正是站在UML和其他各种软件基础理论巨人的肩膀上，成就了当代软件产业的辉煌。”

　　如果说软件工程是在虚拟的世界描绘出人类对于这世界一切大千万物的美好想象，那么也许UML思想应该是这虚拟世界的古老哲学。他就像卢梭在法国大革命前，描述在《社会契约论》一书中，对这自由世界的期待。书中，叙述了社会结构和社会契约、主权和权利，和运作模式。这本书，奠定了世界民族制度的基石，深刻的影响了世界的发展史。　　

　　正如西方古典哲学在现代社会逐渐式微，成为少数内心丰满者们填充自己精神世界的宝贵食物，UML也这样；互联网技术飞速发展的今天，各类软件设计思想层出不穷，正是站在UML和其他各种软件基础理论巨人的肩膀上，成就了当代软件产业的辉煌。但是也必须承认到，UML就像成为案牍上的新华字典，它也许曾经璀璨夺目，而今却积满灰尘。尤其是目前的软件思想，更多的是侧重于更快更好的完成项目，重开发，轻设计实际上是普遍现象。事实上，UML一开始，也是计算机专业课程中一颗难以采摘的艰涩果实，在追求互联网速度的今天，被大家选择性的遗忘也是情理之中，但UML是一种非常宝贵的财富，了解UML，并适当的使用，将让我们真正理解软件设计的真谛。

640?wx_fmt=jpeg

—

领域驱动建模与模型驱动设计

上一篇提到，领域驱动设计的核心是建模。而采用的建模方法就是UML建模。在我们的软件设计过程中，有两种截然相反的设计理念。一种理念是，一切皆抽象，把整个系统设计成一张无比巨大的类图，这个类图简直包罗万象，与当前项目有关的所有方面都一一呈现。另外一种是没有设计，没有对象建模，先搭一个快速原型，然后不断的累积功能，没有设计模式中需要用到的泛化或抽象的思想。

领域驱动设计认为，不合时宜的设计或者没有设计，对于复杂项目来说，根本就是举步维艰。而且，如果某些复杂项目确实尝试使用某些形式的领域模型，但是没有把模型与代码的编写紧密的联系起来，这样的模型也无法确保软件的正确性。在实际项目中，领域模型的建立也是分析知识，消化吸收的过程，如果分析与设计存在分歧，那么在分析和设计活动中所获得的知识将毫无价值。

领域驱动设计使用模型驱动设计的方法来解决这些问题。它期望通过不再将分析模型和程序设计分离开，寻求一种能够兼顾两方面需求的单一模型。软件系统的每个部分，都在模型中体现。即使更加深层次的领域概念，也应该如此。模型不应该只满足设计需求，也要满足开发需求，更需要支持健壮性的通用语言。

领域驱动设计中采用模型驱动设计的模式，期待达到的目标是，通过模型获取用于程序设计和基本职责分配的术语，让程序代码成为模型的表达。同时，也对后期的其他活动造成影响。不同的子系统往往要建立不同的模型，而从需求分析到代码过程中，不应该额外设计过多的模型，这意味着，模型是单独为某一块业务设计的。

—

UML，为设计而生

为了设计每个子系统的单独模型，需要对业务进行仔细咀嚼，消化好知识，研究模型的每个选项，并细化为使用的软件元素，通过UML让软件设计本身成为一个高效运转，不断迭代的模式。

统一建模语言（UML，UnifiedModelingLanguage）是面向对象软件的标准化建模语言。UML因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。UML的目标是以面向对象图的方式来描述任何类型的系统，具有很广泛的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统的执行过程等。

前文提到过，UML如同《社会契约论》这本书一般，对软件工程学进行了定义，它主要是通过一系列模型和关联关系来进行约定的。可以说，UML是软件工程学中最基本的范式，这种范式最终影响了我们所设计的软件产品的方方面面。

UML系统设计过程中，常见的图表主要由三种不同应用视角的模型。

1、首先是分别是功能模型，这种模型聚焦于以用户角度展示系统的功能，例如用例图。用例图定义一个软件系统中的基本角色类型。用例图也是一种静态的图表，更侧重于抽象化系统参与者本身，而不是行为特征，如同社会契约中的不同社会角色。

2、其次是对象模型，采用对象、属性、操作、关联等概念展示系统的结构和基础，包括类图、对象图、包图。类图，侧重于对对象的状态和行为特征进行定义，更加注重于具体的执行层面。其实类图也是软件系统中最常见的图表，通过类图，可以便于让开发者了解不同领域之间的关系。对象图与类图本质上的作用类似，均代表一种特征明确的单元对象或者实体，不过与类图相比，对象图实际上是偏业务层面，而类图偏代码层面。对象图和类图都是边界清晰的对象，通过状态，行为，标识进行区分。对象图是一个空间或时间维度对象在软件世界的投影，而类图是抽象对象的具体实现结构。包图也是模型对象的组合，通过包图可以将不同类型的对象按照一定的特征进行结构化和更加合理的逻辑定义。

3、再次是动态模型，主要显示系统的内部行为。包括时序图，活动图、状态图。时序图显示时间维度上不同对象的执行步骤和接口方式，每一个消息代表一个类的操作，或者其他对象的行为触发。活动图，表示对象间正在进行的事件状态，体现的是对象间在不同阶段的状态切换，活动图侧重于对象内部，或对象间动态的执行过程中，状态变化。看起来活动图与流程图类似，但流程图侧重于表现对象间的顺序和时间关系。活动图也似乎与状态图类似，不过区别在于状态图表示单一对象的在不同阶段的状态变化。

对象间的联系，类似于现实社会中实体对象的权利和义务以及伦理观念。在UML中，关系很多，而且在不同的版本，或不同的设计软件中，都有不同形式的关系表现。而常见的关系有泛化，实现，关联，组合，聚合，依赖等。

【泛化】，作为一种继承关系，定义父类的特征和行为，并对子类如何表现这种特征和行为进行了约束。例如现代语言中的子类和超类之间，就是一种泛化关系。

【实现】，类与接口之间的关系。接口作为契约，而类作为具体执行者，去执行相应的契约。

【关联】，建立不同类之间的联系，这种联系包括单向或双向的联系，例如情人之间，互相可以共享对方拥有的资源，而类与类之间建立了联系之后，也可以实现对方的某些属性或行为。

【聚合】，表征一个对象和它的子对象间的关系，子对象在其业务范围拥有一定的独立权，但是在更大的层面，可能需要父对象类体现。

【组合】，组合关系同样是表示对象与对象间存在整体与部分间的关系，但子类无法脱离父类而存在。

【依赖】，体现一个对象的实现需要另外一个类的协助，缺少依赖性，将导致对象无法运转。依赖又分成直接依赖，间接依赖，循环依赖，双向依赖等说法，过于复杂的依赖关系将提高系统的耦合性。

—

结语

如我本文开头所说，UML其实是一种古老哲学，它定义了软件设计过程的基本结构、关系、和职责，对软件工业的标准化发挥了不可磨灭的共享。因此在实践领域驱动设计过程中，同样也应该使用UML这种优秀的建模理论作为辅助，设计和实现符合业务需求、开发模式的软件系统。

　十多年前，我就读于湘中小城，当时的专业是信息与计算科学，实际上这是数学系下的一个交叉学科，我们班大部分同学都是调剂生，而我却是为数不多的第一志愿录取。在我们专业开设的一堆数字加计算机课程中，最感兴趣的是软件工程，最记忆犹新的也是uml，然而参加工作以后发现，其实应用得非常少，真的是因为它不实用吗？其实一方面是因为软件公司的成熟度还不够，一方面也是盲目的选择不适合的模式，并不一定能带来效率的提高，彼之蜜糖，吾之砒霜。应当根据企业实际出发，建立更加利于执行的范式，形成一套属于企业自己的、简约、易于执行、便于扩展的约束。UML这种思想其实已经渗透到我们工作中的方方面面，在领域设计过程中，尤其需要使用它来打造更美的设计。