1、是什么

模型

• 首先，模型是以解决特定问题为目的的
  

• 第二，模型都是对现实世界或人们思维中的事物进行的模拟

  第三，模型总是提取了被模拟事物中的部分信息，而忽略掉了其他大部分信息

  第四，模型可以有多种表现形式，例如图纸、影像、公式以及电脑中的文件等等。

• 最后，模型是一种人造物，大自然本身是不存在模型的。

领域模型

• 是概念模型

  描述的是现实世界的实体和他们之间的关系
  

• 我们系统中要处理的各种“事物”

  名词性的概念

  名词化了的动词，比如支付

  辅助理解
  

• 软件开发是一个建模过程

  在分析步骤产生的分析模型，也叫做领域模型。

  领域：软件解决的问题域，模型：分析模型

2、主要作用

将知识可视化，准确、深刻地反映领域知识，并且在业务和技术人员之间达成一致；

• 1、知识传递
  

• 技术同学说：我没太懂你到底想要个啥玩意儿

  产品同学说：好，让我跟你再细说说

  2、知识提炼
  

• 技术同学说：你讲的我大概都明白了，但是就感觉有些凌乱，东扯一下，西扯一下，还是有点迷糊

  产品同学说：好，那我们再来梳理一下，有些点确实可以归归类啥的，可能更方便理解

  3、可视化
  

• 技术同学：嗯，你的需求我基本是了解了，要不我把我的理解画出来，跟你确认一下？

  产品同学：好主意，那咱们一起来搞吧。

  4、认知对齐
  

• 技术同学：你看我画的这个，是那个意思哈，确定哈。 还有这个这个，是那个那个意思哈。

  产品同学：对的对的，这个是对的。 不过，那个可能稍微再调整一下更符合实情业务情况。

  5、统一语言
  

• 技术同学：看来，咱们画这一波图，已经把需求的要点都囊括了哈。只是有些概念我感觉还是有点模棱两可，要不咱们再对一下，把这些概念的叫法给定死咯，这样我写代码的时候，也方便取名字。

  产品同学：要得要得，我们再拉一个表吧，把所有的业务概念再罗列一遍，包括中文表达和对应的英文表达都敲定一下，以后咱们就以这个术语表为准来沟通。

指导系统的设计和编码，也就是说，领域模型应该能够比较容易地转化成数据库模式和代码实现。

3、核心优势

通过模型驱动设计与统一语言保证两个一致，最大程度避免了系统实现和业务需求差距越来越大，导致的软件迭代效率低下、甚至无法支撑业务的难题

• 领域模型要和业务需求一致；

• 事件风暴仅仅追求“形似”，也就是说业务是怎样运作的，事件风暴就怎样反映。
  

• 而领域模型不仅要和需求“形似”，更要“神似”。也就是说，领域模型不仅要对业务进行直观模拟，更要经过提炼，形成浓缩的知识。

  第一点，是通过抽象思维得到更“深刻”的模型。

• 第二点，是通过深入思考得到更“丰富”的模型。

  系统实现要和领域模型一致。

  如果修改了领域模型，那么系统实现必然也要修改；

  反之，如果系统实现发生了变化，也很有可能导致模型的变化。

  领域模型中的每个元素，都应该通过某种方式在系统实现中有所体现
  

高质量领域模型对开发效率有质的提升，特征

• 建立共识

  产生洞察

  持续演进

4、缺乏领域模型的一些信号

• 组织中没有关于概念的共识

• 沟通误解和不必要的需求变更

• 看似容易支持的业务涉及到系统的许多改动点

• 架构可理解性和可维护性不足，容易发生意料之外的问题

• ......

5、表达方式

可以使用 UML 类图来描述

6、与传统方法的区别

传统的开发过程

DDD 的开发过程

DDD 强调领域模型要兼顾业务和技术两个视角

技术和业务同频；技术和业务重叠部分达成一致