《领域驱动设计》速读之一：领域驱动开发的基本概念及目标

今天再看了一遍《领域驱动设计》这本书，感觉还是有不少收获，打算做个系列，先跟大家分享书中第一部分的内容：领域驱动开发的基本目标。

零、太长不看版本

• 领域驱动设计是一组思维方式，也是一组优先任务，旨在加速那些必须处理复杂领域的软件项目的开发。

• 领域驱动设计一书假定的前提：

• • 项目的主要焦点是领域和领域逻辑

  • 复杂的领域设计应基于模型

  • 项目组采用迭代开发

  • 开发人员与领域专家（需求方、产品）有密切关系

• 软件的核心：为用户解决领域相关的问题的能力

• 模型：为解决某个方面的问题而对事物的精简抽象

• • 如 地图是模型、UML类图也是模型

  • 如 有面向业务分析的模型、面向软件设计的模型

• 本书引入领域模型概念，其是为了同时解决业务分析及软件设计两个方面问题而共用的单一模型

• • 模型结合业务及设计，能发现更加细节逻辑，指导业务开发的同时完善领域业务自身

  • 该模型跨分工共享，能统一概念，辅助构建全项目组（领域专家、开发、设计等）通用语言，协助填平领域专家与开发之间交流的鸿沟

• 业务分析模型与软件设计模型必须统一，否则

• • 分析模型到设计模型转换必然会存在信息丢失

  • 无法构建统一的通用语言

  • 无法从软件设计实现细节反向支撑领域分析

• 领域驱动设计核心理念：通过使用全项目组的通用语言（Ubiquitous Languaage），让领域专家及开发在同一水平面上一起讨论和设计一个既适用于分析业务也适用于开发设计的模型，同时在开发时绑定模型与具体代码的实现，以此减少沟通转换成本，做到项目高效协作。同时由于模型绑定实现的原因，使得封装逻辑粒度主要变为类，提高了代码的可维护性及可阅读性。

以下为详细内容。

壹、使用模型分析及消化知识

通过与领域专家的持续交流过程中一起创建模型、迭代完善模型。迭代过程中，程序员与领域专家都能获得知识：

• 程序员获得领域知识

• 领域专家在梳理领域模型时，完善自身的认识、完善领域自身的设计

贰、项目中的交流

当领域专家、设计及开发能高效地交流时，项目就已经成功了一半。

项目领域通用语言

项目领域通用语言是各方（领域专家、设计、开发）都能无二义地描述领域相关问题的语言。其一个重要组成部分包括：共享、唯一的领域模型。

• 目的：减少交流中的翻译转化成本及误差

• 形成过程：在持续的交流过程中定义及明确（其中一部分包括领域模型的形成及修改）

建议：在交流过程中应大量、经常地使用领域模型，以减少沟通成本

通用语言包括：

• 领域模型

• BoundedContexts(见后续)

• 大型结构的术语

• 一些通用模式名称

其不包括：

• 业务不懂的技术术语

• 开发不懂的业务术语

沟通中使用的图和文档

作者对如何使用图和文档提了一些自己的看法。

如何使用UML图协助交流：

• 不要尝试将所有细节都放入到UML中，这样只见树木不见森林

• 要以文字为主，以精心挑选的简化后的图为辅，沟通时再加上自然语言的讨论以完善细节

• 更细节的信息应该存储于代码中

如何编写文档（业务领域相关）：

• 文档大多情况下难以跟着代码演进，因为代码演进不一定需要文档的支持

• 推荐两类做法：

• • 极简文档：只描述较大维度的设计思想，具体的实现应该只在于代码当中

  • XP模式（极限编程模式）:良好的代码有很强的表达能力，几乎全依赖于具体代码以及测试案例以代替文档。这要求编码人员要有一丝不苟的态度。

叁、统一业务分析模型及软件设计模型

领域专家与分析人员可能完善的设计出了模型，但若开发时，并不能直接将模型对应到实现，直接指导开发的话，模型设计的意义就会大大减少。

领域驱动设计要求模型不仅能尽早地指导早期分析的工作，还应成为软件设计实现的基础。

模式：Model-Driven-Design 模型驱动设计

模型驱动设计指代 软件元素的某个子集严格对应于模型的元素，也代表着一种合作开发模型和实现一遍互相保持一致的过程。其为实现领域驱动设计的一个子集。

存在一种想法就是 业务领域分析模型（后称分析模型）可以与具体的模型实现分离，因为其关注点不同，但实际上这样做有很多坏处：

• 分析模型到软件设计实现模型存在转换，可能存在信息丢失

• 软件设计模型通常考虑到更为细节的点，而分析模型可能分析较为宽泛，导致分析模型并不严谨完善

• 分析模型与实现模型不同存在额外维护成本，难以共享技术实现以及领域业务分析者的进度及知识

• 存在不同的模型（分析模型、实现模型）不便于构建一个健壮好用的项目领域通用语言

因此我们分析用的模型以及软件设计实现使用的模型必须要统一，设计实现必须如实反应模型，模型也需要反复地修改，以便更自然的实现模型。

要实现建模与软件设计实现的统一，通常要使用面向对象的编程语言。

分析/设计模型 与 用户模型

Model-Drivern Design要求只使用一个模型，这里通常指代的是 分析模型 与 软件设计模型。但在本节将额外讨论一个用户模型。

领域模型（分析/设计模型）大多数情况下是不便于用户使用的，但领域模型 与 用户模型 的表现不同时，可能会导致用户产生误解。

因此如果可以，我们还是尽可能地统一这三个模型，但若不能，也没关系。

模式：HANDS-ON MODELER

不能将建模工作与代码实现工作过度地分离。因为建模与开发完全分离的话:

• 会导致建模信息的丢失，若紧密配合工作，则能传导模型思想及检验代码是否符合模型的思想

• 会导致无法根据具体实现的问题反向修正模型

任何参与建模的技术人员都要画时间了解代码，任何负责修改代码的人都必须学会用代码表示模型。

肆、附

实际上这里已经有很多的知识点，若大家有任何疑问，或者对文章内容有任何意义，欢迎流言评论。