[架构之路-97]：《软件架构设计：程序员向架构师转型必备》-7-业务需求之领域建模

前言：

需求分析工程师或产品经理的工作在业务领域，而业务领域有很多业务领域专有的概念；

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

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

领域模型是对用例图的进一步细化！！！

领域模型是分析师两大职责之一：

• 需求分析：描述的是业务需求+业务流程

• 领域建模：描述的不是业务需求，而是对业务领域或问题领域关键概念的抽象！！！领域建模是探索问题领域的工具，可以帮助分析师探索和提炼问题领域的知识！！！领域 建模不一定是站在用户的角度审视领域系统。因此，领域建模不是用例图的一部分！！！也不是用例建模的工具！！！因此，领域通常只包含概念类图和状态图，不包括时序图和业务流程图！！！！领域建模是挖掘隐藏在用户功能需求背后的问题领域的核心概念，这些概念是用户、系统分析师、系统架构师、软件开发人员公认的、达成共识的关于目标系统的词汇。这些概念最终会通过编程语言的对象或结构体来表述。

第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）——可扩展性

结束语：

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

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

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

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