前言：

需求分析工程师工作中业务领域，而业务领域有很多业务领域专有的概念；

程序员主要工作在计算机领域，他们没有足够的业务领域的知识识别业务领域的过于专业化的业务需求。

为了确保业务需求能够被软件工程师正确无误地实现，就需要需求分析工程师或架构师为业务领域建立计算机领域的抽象模型，这个模型称为业务领域模型。

第7章 业务需求领域建模

7.1 什么是领域模型

业务领域模型是需求分析人员的职责，以便于更好使用相同的“语言”与面向对象的程序员之间沟通业务需求，这就是业务领域模型的价值与意义。

7.1.1 业务领域模型的定义？

备注：

所以领域，就是业务领域，如5G移动通信、数据通信、医疗、金融、交通、电力这些都是业务领域。

每个的领域都拥有大量的专业化的专有名词和业务流程，然而，无论这些领域的专业知识如何变化，实际上都可以通过面向对象的编程，如C++或Java等编程语言实现。

为了平缓业务领域的专业性和面向对象编程语言的通用性之间的差别，业务领域模型应运而生。

7.1.2 业务领域模型是什么？

备注：

类图：使用面向对象的方法抽象业务领域中存在的各种静态概念。

状态图：使用状态机描述业务领域内特有的各种业务状态轮转。

业务领域模型已经具备一定的架构设计，因此通常有需求分析工程师或架构师，而不是程序员来完成此任务。

架构师或需求分析工程师：根据对需求的理解和面向对象的理解，对需求领域的概念和业务状态进行抽象。有了这些模型，程序员就很容易根据领域模型和面向对象编程的技能，对目标系统进行编程实现了。

7.1.3 业务领域模型“为什么”

7.2 需求人员视角——促进用户沟通、解决分析瘫痪

7.2.1 领域建模与需求分析的关系

7.2.2 沟通不足

7.2.3 分析瘫痪

7.2.4 案例：多步领域建模，熟悉陌生领域

7.3 开发人员视角——破解“领域知识不足”死结

7.3.1 领域模型作为“理解领域的手段”

7.3.2 案例：从词汇表到领域模型

7.4 实际应用（5）——功能决定如何建模，模型决定功能扩展

7.4.1 案例：模型决定功能扩展

备注：领域模型是专业业务领域与通用的计算机领域的桥梁。

7.4.2 实践：功能决定如何建模

7.4.3 PM Suite领域建模实录（1）——类图

类图是领域建模师（架构师或需求分析人员）同专业领域专家逐步讨论、逐步细化出来的！！！

请看如下案例：

7.4.4 PM Suite领域建模实录（2）——状态图

7.4.5 PM Suite领域建模实录（3）——可扩展性

结束语：

至此，需求领域的任务就完成了......

后续就是就架构设计领域的任务了.......

本章既是专业业务领域的需求，也是计算机领域的设计，是有架构师或业务分析人员与业务领域的专家共同确定的、用面向对象的方法表达的业务领域的需求，同时也是对计算机软件的需求。

业务领域模型在专业的业务领域与计算机领域架起的一座桥梁！！！