业务概念模型，你必须知道的建模分析工具

引言

回想经历过不同的团队、不同的产品线、大量的产品需求迭代建设，在系统建设（多数是业务系统）中往往偏重于方案域求解，比如，而弱化或忽视对问题域的分析建模。这篇短文章浅谈一下“业务概念模型”，希望对大家有所帮助。

什么是业务概念模型

对于概念模型我们并不陌生，其本质是模型，是对某个域信息的建模，例如常见的E-R图是对数据模型的建模。多数情况下，作为技术我们更多的接触的是技术域的分析与建模。业务概念模型（Business Conceptual Model）是一种用于描述业务领域核心概念及其关系的工具，业务概念模型的本质在于语言对齐（或统一语言）。它通过定义业务术语及其关系，建立业务团队与技术团队之间的共同语言，确保双方对业务需求的理解一致。业务概念模型是技术无关的，其不涉及技术实现细节，而是专注于业务域逻辑的抽象与表达。

业务概念模型的表述可以使用多种方式，但一般建议采用图形化方式，比如线框图、类图、概念图等均可。无论采用哪种方式，业务概念模型的核心在于简洁性与清晰性，避免引入技术细节。

其核心价值体现在以下几个方面：

1.通过统一业务术语，减少业务团队与技术团队之间的误解。

2.明确业务规则，清晰描述业务概念之间的关系，为后续系统设计提供基础。

3.支持需求分析，帮助业务团队梳理需求，发现潜在的业务问题。

4.衔接领域模型，为领域驱动设计（DDD）中的领域模型提供输入。

业务概念模型与领域模型的差异

业务概念模型和领域模型是两个关键概念，但其有本质区别。

业务概念模型的核心是语言对齐，在问题域建模。它通过定义业务术语及其关系，建立业务团队与技术团队之间的共同语言，确保双方对业务需求的理解一致。其本质是沟通工具，目的是解决“如何谈论业务”的问题。

领域模型的核心是业务逻辑的捕捉与实现，在方案域建模。它通过定义领域对象及其行为，将业务需求转化为可执行的系统设计。其本质是设计工具，目的是解决“如何实现业务”的问题。

它们虽然密切相关，但在目标、抽象层次和应用场景上存在显著差异

目标差异

业务概念模型的目标是：统一业务语言，确保业务团队与技术团队使用一致的术语；明确业务规则，描述业务概念之间的关系及其约束；支持需求分析：帮助业务团队梳理需求，发现潜在的业务问题。

领域模型的目标是捕捉业务逻辑：将业务需求转化为可执行的系统设计；定义领域对象的行为及其交互方式，指导系统实现；为技术团队提供设计依据，确保系统符合业务需求，支持技术决策

抽象层次

业务概念模型是高层次的抽象，专注于业务术语及其关系的定义。它不涉及技术实现细节，而是从业务视角描述业务逻辑。

领域模型是细粒度的抽象，专注于业务逻辑的实现。它从技术视角描述领域对象的行为及其交互方式，可能涉及技术细节。

应用场景

业务概念模型的应用场景：在业务分析阶段用于梳理业务需求，建立业务语言一致性。在需求沟通阶段作为业务团队与技术团队的沟通工具。在需求文档编写作为需求文档的一部分描述业务逻辑。

领域模型的应用场景：在系统设计阶段用于指导系统设计，捕捉业务逻辑。在技术实现阶段作为技术团队的设计依据，定义领域对象的行为。在代码编写阶段作为代码实现的参考，确保系统符合业务需求。

业务概念模型和领域模型相辅相成，都是支持统一语言的有效工具。业务概念模型通过定义业务术语及其关系，为领域模型提供了清晰的语言基础；领域模型则在此基础上，将业务需求转化为可执行的系统设计，定义领域对象及其行为，确保系统实现符合业务需求。业务概念模型解决“如何谈论业务”的问题，领域模型解决“如何实现业务”的问题。

团队实践业务概念模型的典型问题

业务概念模型建模的关键是需要在工程中不断的实践和迭代，对于开始基于业务概念模型进行建模的业务或技术人员来说，以下可能是经常出现以及应该避免的问题：

团队意识：技术人员往往弱化对业务模式信息的汲取，不愿意花费精力去参与分析建模。这种团队业务建模分析的意识欠缺是对落地实践最大的阻碍。

协作屏障：作为业务分析的辅助实践，要进行业务概念模型建模需要在干系人（往往包含了业务与技术人员）间垮团队或岗位进行协作，传统的团队组成形式和研发方式往往是这种协作会有一些割裂，比如研发一般会直接对接产品经理，而很少与一线业务人员直接沟通。

模型表述复杂化：模型很容易复杂化，比如为了追求覆盖而过度详细、过多且不统一的图形话元素、复杂的关系及泛化表示、引入技术概念等等。业务概念模型的目标是通过建模过程及建模结果在干系人间达成对业务域清晰一致的理解，凡是对该目标造成阻碍的实践均应该尽量避免或优化

忽略模型验证与迭代：建模能是闭门造车，干系人尽量参与到建模的分析过程中去，最大化的在干系人间达成信息的一致理解。同时，随着业务发展，业务概念模型也应该随着逐步迭代优化。

在实践业务概念模型辅助业务分析要保持如下几个原则：

1. 以业务为中心：始终围绕业务需求设计模型。

2.保持简洁，在满足目标的前提下避免过度复杂化

3.确保干系人间一致性理解

4.维持维持模型的迭代更新

常见的疑问

1. 是否应该表述模型间的重数？

重数（Multiplicity）描述了业务概念之间的数量关系，适当的、明确的重数表示可以更准确的定义业务规则，有助于澄清业务需求。但过多的重数表示会增加概念模型的认知复杂度，不利于干系人对模型达成一致理解。是否需要表示重数，以及表述多少没有固定规则，需要具体情况具体分析。当需要使用重数明确需要表述或强调某个特定的业务规则时则使用，反之则弱化。

2. 是否应该在概念间引入泛化关系？

具体情况具体分析！泛化（Generalization）用于描述业务概念的分类关系，同样，泛化关系能够使得概念模型的表达更准确、业务语义更丰富，有利于业务概念对齐。但泛化会非技术干系人不太友好，过多的泛化表示会增加模型复杂度。例如业务团队不熟悉该概念，或者要泛化表示的子概念在当前分析阶段不重要是则不需要引入泛化。

3. 是否应该引入双向关系？

具体情况具体分析！双向关系描述了业务概念之间的相互依赖。是否引入双向关系需谨慎。当业务概念之间的相互依赖对业务规则至关重要时，例如“订单”与“客户”。当双向关系会增加模型复杂度，或对业务团队不重要时。

4. 是否应该存在多条同方向关系？

具体情况具体分析！多条同方向关系描述了业务概念之间的多重关联，在需要明确表述多个业务关系时则建立，反之则不需要。

5. 什么场景在表达关联关系的线上不需要进行文字说明？

存在文字表述的唯一目的是有助于对模型关系的理解澄清。如果在已经非常明确、显而易见的关系则不需要进行文字说明。

结语

业务概念模型是业务分析建模的有效工具之一，是连接业务与技术的桥梁，通过概念模型在干系人间统一语言、达成共识，并未后续设计提供输入。在设计业务概念模型时，应始秉持业务视角，避免技术概念的引入，在能满足信息一致理解的前提下，保持模型的简洁性与清晰。