天天写业务代码，如何破局业务开发的本质？

👉导读

无法与业务耦合的开发工程师，职业发展往往更易触碰到天花板。只有在经历过快速迭代的业务需求锤炼、海量用户规模场景的“拷打”以后，工程师才能向架构师甚至更高的技术岗位进阶。腾讯技术专家，万字长文带你剖析业务开发的本质！长文干货，建议先点赞收藏！

👉目录

1 业务问题2 开发挑战3 业务建模4 总结5 附录

01

业务问题

   1.1 关于业务

业务（Business）：在大多数情况下，表示一个组织、公司或个人所从事的商业活动、服务或工作，有相应的流程和规则。可以理解为达成某种目的（如盈利、增长、满足客户需求等）所进行的各种活动，涉及到如何创建价值、满足需求和实现目标。

业务相关活动所涉及的问题范围，即问题域（Business Domain），问题域通常也就是公司为其客户提供的服务。

以支付业务为例：

• 支付，是一种经济活动，有经济活动就有支付需求。其业务流程覆盖交易，清算和结算过程（即互动行为，信息流动以及资金流动）。
• 支付，是金融体系最重要和最基础的功能，涉及到行为众多参与方的共同活动，因此又关系到相关的行业标准/规范和法律法规。

支付业务从等价物交换，到货币支付，再进入电子支付，从单纯银行卡收单走向第三方支付平台。而第三方支付所研究的问题从起初的面向商业场景的收单，走向面向用户的电子钱包到面向企业及行业的资金运用效率的问题。如果说央行支付清算体系是社会经济的大动脉，那么第三方支付就是连通全社会的分支血管和毛细血管。

   1.2 关于产品

产品，通常是指对应的业务背景下为相关问题域提供的解决方案，即为用户/目标组织所提供的系统或服务。

针对支付业务，市场上面向用户提供了各种类型的产品，如面向线下收单的各类解决方案，到现在的第三方支付平台“微信支付”、“支付宝”上面向业务诉求和场景所提供支付产品。从业务问题域侧重点的差异可以看到产品形态的差异。

• 微信支付：为个人和企业提借在线支付服务，产品有支付产品（付款码支付、小程序支付...）。
• 支付宝：相关产品（App 支付，当面付...）、营销产品（商家券...），资金产品（花呗分期..）。

支付产品服务的用户和目标组织，包含支付网络中连接到的个人、企业、商家和其他组织机构。比如，线下或线上的各类商家、各行业的服务提供商、甚至政府机构，也比如小商户，或需要收付款的任何个体等。他们因在支付服务中获得价值而使用并提出各类需求。

   1.3 关于系统

产品是对解决方案的包装，支撑起解决方案的实现即系统（业务系统）。如：

• 银联业务背后的 CUPS 系统(China UnionPay System)
• 微信支付背后的微信支付系统(WeChat Pay System)

公司向市场提供的每种产品都是执行各类活动的结果。而信息系统在业务流程管理中应发挥重要作用，因为公司执行的越来越多的活动都得到信息系统的支持。业务流程中的活动可以由公司员工手动或借助信息系统来执行。还有一些业务流程活动可以由信息系统自动执行，无需任何人工参与。只有人与其他企业资源（例如信息系统）良好地协同工作，企业或组织才能高效、有效地实现其业务目标。业务流程是促进这种有效协作的重要概念。

在非科技行业的各类公司中，组织的业务方面与现有信息技术之间存在差距。缩小组织和技术之间的差距非常重要，因为在当今充满活力和竞争的市场中，公司必须得向客户提供更好的产品/服务才能生存。而信息系统让公司和组织，甚至行业得以大幅提效。

这里的信息系统，即面向业务改进所建设的软件系统，即业务开发所交付的“业务系统”。

再以支付为例，其业务边界和业务形态的演变，得力于信息系统逐步对业务流程不断改进（如信息流/资金流）。其所形成的支付系统的形成过程，正是通过对支付业务的问题域不断研究的结果，通过流程改造、自动化和信息化替代人工流程，将支付解决方案不断提效、拓展、升级的过程。

02

开发挑战

业务就是为客户提供价值以获取利润。经营企业就是有能力预判并做出决策，而信息是决策质量最重要的决定因素。信息系统的设计必须确保所提供的信息及时、准确且充分相关。只有当我们了解做出这些决策的背景时，我们才能确保信息系统以这种方式支持业务决策。

业务开发，冠以“业务”前缀，要的是在技术通识的基础上，更要熟悉业务。是另一个维度的全栈（业务+技术）能力。

业务开发团队，要承接并交付出“好”的业务系统，挑战在两点：

1. 从0到1阶段：洞察用户痛点，解决核心用户问题。
2. 1到100阶段：业务系统能轻松的高质量的动态进化,在不断发展中支持业务攻城略地。

这也是大多数团队所面临的挑战：

• 洞察痛点：本质在于理解业务，能够于定义边界/聚焦重点
• 【面向需求】要开发什么样的产品？
• 【面向业务】为什么要开发这个产品？要解决什么问题，达成什么目标？
• 动态进化：本质依托于业务系统的设计和实现
• 【面向设计】如何做才能契合业务形态应对变化、减少制约以更好的达成目标？

以微信支付的红包产品为例：

• 回顾需求：将线下红包收发场景线上化，有普通红包，群红包，摇红包...
• 背后业务：红包业务：账户/资金流/业务流程...业务目标：拉新，绑卡，入金，活跃，...
• 设计实现：要对接用户/商户/金融机构，高效准确的处理资金的收付退；面向节假日高峰，系统架构如何定义和应对...

业务上“知其然知其所以然”，将有能力优化业务流程，准确评估需求甚至发现需求，甚至建立预判能力，为业务系统构建灵活运营能力，更好的提升产品市场地位。

业务开发的挑战，这里探讨两点：1-理解业务，2-融入业务视角来设计/构建系统。

注：本篇先探讨第一部分。第二部分在下一篇继续。

   2.1 理解业务

理解业务，需要以全面透彻的视角看业务，了解涉众诉求、利益关系以及价值链。做为业务开发，读/写代码、转换用户视角使用产品功能外，要从行业发展过程和法规管控原因去理解业务。

对于技术要承载的业务，要跳出单一代码视角，从两种视角拆开看：

• 问题空间（Problem）：即业务的问题域，探讨和关注的是有什么问题要解决，或者存在什么痛点要消除，也即需求；
• 解空间（Solution）：也称解决方案域，考虑有哪些方案去解决这些问题；最终用哪个方案做到了，称为实现。

区分这两部分的意义在于：提问题比解决问题更重要。

提对问题，才能找对方向，给出多种方案，才能控制风险防止南辕北辙。

在工作过程中，需要将两方面分开讨论，而不是混淆在一起。这能帮助我们把注意力放到要聚焦的问题本身，去关注用户想要什么（Want）、痛在哪里，再去列举可能的解决方案（How）。反之，轻则只理解表面上的交互流程，导致面向 UI 开发 （例如，将领域逻辑和业务规则直接写到 UI 层或者写成 Transaction Script，导致实则是应该被领域对象管控的业务规则被分散到各处而失去维护性）；重则方向性错误，前功尽弃。

动手之前，通过面向业务提好的问题，能帮助我们发现业务本质、覆盖全局且不留死角。

初识业务，或者成熟业务上扩展出新需求，需要主动思考：

• 这个业务，现状是什么样的，为谁服务？
• 这个业务，全景是怎样的？上下游、合作方涉及哪些内容？他们是怎么合作的？
• 这个业务，最核心的价值在哪里？利润从何而来？
• 这个业务，最重要的待解决的问题是什么？
• 这个业务，当前市面上有哪些解决方案，这些产品是以什么思路设计的？
• ...

在探讨上述问题之后，还可进一步应用熟悉业务，比如：

方法	目的	特点	工具
使用产品	了解产品使命、愿景、用户，全方位的使用产品，了解产品整体运营情况	产品经理视角	产品体验报告
熟悉业务	学习相关领域的专业知识、掌握术语/行话（建立名词表），甚至参加资格考试，学习业务分析材料、研究论文等资料	学科专业知识	专业学科材料
用户调研	与用户交流，了解用户体验和需求，获取不同用户群体的第一手一线信息	用户满意度	线下访谈
分析竞品	产品/竞争对手产品分析，了解并对比产品和服务的特点、优势和不足	发现机会和创新点	对手产品
阅读行业报告	行业调查/背景调研，全局的了解行业的发展趋势，竞争态势和主要挑战	全局视角	研报网
参加行业活动	加所在行业的活动，如研讨会、培训班、展览等，获取行业最新动态	前沿视角	行业峰会
加入专家网络	与所在行业的专家建立联系，以获取行业的专业知识和经验	专家视角	人际网络

团队虽面向需求切入，在需要在过程中提炼总结并沉淀领域知识，提升对业务理解力和敏感度。

一边提问一边参与项目实践，类似运用（Problem-Based Learning+Project-Based Learning）结合的学习模式，能快速帮助团队提升对业务的感觉。

有了对业务的整体认识，将建立起足够的判断力，帮助高效对接/厘清业务，放大价值贡献。开发团队将更好以业务视角按目标业务架构来交付一致匹配的业务系统。

   2.2 做对需求

需求不仅仅是 TAPD 上的表面的交互或说明，其本质是要基于业务背景为用户创造价值。功能需求是用户价值点，而非功能需求则为产品放大竞争力（对应的质量属性，如用户体验、性能、兼容性，安全性等）。

对于纯互联网 C 端产品，多以工具型产品为主，本身构建于数字化基础体系之上，且问题域的涉众相对角色少（开发者自身就是核心用户）。其需求更多以点状出现，然后通过 MVP 和原型化的方法在过程中进行快速试错进行验证和提炼，这样的需求多会以交互/用户故事轻量化的管理和呈现。

但在 B 端或面向行业，其业务流程长且内禀逻辑复杂，业务场景下参与的角色众多，而且领域专家和解决方案团队大多并未重合，开发者需要跨领域学习业务知识，比如金融/证券/保险的业务，又或者是零售/消费电子制造等行业都有自身行话术语，以及产品内的特定业务流程和业务规则。

这种场景下，对于业务系统的建设团队的挑战有：

• 需求背后涉及的业务，其目标组织是如何运作和分工协作以执行业务活动的
• 如何让团队成员准确理解和评估最终用户的需求，和目标组织就业务系统的价值达成共识
• 如何让大型团队协作的成员之间的理解一致，以防止出现实现不一致
• 如何业务知识如何有效沉淀和迭代，而不因团队变化导致信息缺失
• 如何为业务建设出匹配的可长期运营的业务系统，而不在演进过程中发现重大缺陷......

相信大型、跨多团队协作建设和运营的长生命周期业务系统会有同感。

对于支付业务，在为不同行业的企业/商家提供有竞争力的在支付/资金解决方案过程中，更感受到透过产品表面形态穿透业务本身的意义和价值。此处的不断实践，我们将上述挑战的解决方案落脚于业务建模方法上。

来一起看看：业务建模。

03

业务建模

模型（Model）：几乎所有的创作者都会用模型来表达。当我们想要建造汽车桥梁和建筑物时，我们会先制作模型。当我们想要制作和定义电气设备时，我们会绘制电路图。我们用公式来理解物理、化学和数学。几乎在每一个学科中，我们很自然的使用模型的表达方式来澄清我们在做什么。

模型为我们阐明了某事物或某事件的某些方面或某些观点。为了实现这样的通用目的，模型主要分为静态和动态两种：静态模型呈现结构，动态模型呈现事件流。

建模（Modeling），是一种处理复杂性的手段。建模意味着构建一个系统的抽象，通过抽象模型关注感兴趣的方面并忽略不相关的细节。建模使我们能够通过分而治之的方法处理复杂性：对于我们想要解决的每种类型的问题，我们构建一个仅关注与问题相关的问题的模型。一般来说，建模的重点是建立一个足够简单、可以让人完全掌握的模型。

广义的业务模型（Business Model），用以明确目标组织（公司/组织）的功能，显示其所处的环境以及在环境中的行为方式。此处的环境是公司为执行其业务流程与之交互的所有事物，如客户、合作伙伴、供应商等。业务模型能用于系统的管理公司的发展，帮助降低风险增加成功概率。如：组织架构定义、业务活动的参与角色和执行流程等。

这里打住，回到我们的业务开发语境下的业务建模，是面向业务交付信息系统的目标下所探讨的内容。因此，我们探讨的业务建模（Business Modeling）是指通过对目标用户/组织的业务需求、流程和规则进行分析和描述，并以抽象模型呈现出来，从而为软件系统的需求、分析、设计和实现提供基础的过程。

业务建模能帮助项目团队更好地理解用户的业务背景，发现用户可改进点，确保软件系统与实际业务需求保持一致，更好的提高用户满意度。此外，业务建模还有助于提高项目团队和客户之间的沟通效率，降低项目风险。业务建模通常会通过创建一系列模型（如业务用例模型、业务分析模型等）来表示和组织这些业务需求、流程和规则的过程。

   3.1 业务建模的目标

• 了解目标组织的结构及运行机制；
• 了解目标组织中当前存在的问题并找出改进的潜力（放大价值！）；
• 评估组织变革带来的影响；
• 确保客户、最终用户和开发人员就目标组织达成共识；
• 导出支持目标组织所需的软件系统需求；
• 理解将交付的软件系统如何在目标组织中工作。

业务建模描述了如何评估当前组织并制定新组织的愿景。然后，以该愿景为基础，在业务用例模型和业务分析模型中定义该组织的流程、角色和职责。

可见，业务建模很好的应对了我们在做需求时所提到的挑战：理解业务，做对需求甚至洞察需求。

   3.2 业务建模的技术

业务建模是一种技术，建模语言常见的有 UML 和 BPMN 等，基于通识我们主要使用了 UML。

业务建模的 UML 常用符号如下：

在我们的实践中，多采用序列图来梳理业务流程（实例中的图示感觉很好理解，对吧）。相关业务建模的符号说明如下：

名称	英文	所属模型	备注	示例
业务用例	Business Usecase	业务用例模型	用以表示业务流程。业务用例从外部、增值的角度描述业务流程，其实例都是业务执行的一系列操作，以便为相关涉众提供价值。业务用例必须支持业务目标。	见后续描述
业务执行者	Business Actor	业务用例模型	代表业务环境中某人或某物所扮演的与业务相关的角色	客户，供应商，合作伙伴..
业务工人	Business Worker	业务分析模型	代表人或软件系统在组织内扮演的角色，是人或软件系统的抽象，即业务用例实现中做执行的角色；业务工人互相协作，收到事件通知并操作业务实体来履行其职责；这种抽象使我们能识别业务流程中的潜在改进并考虑业务流程自动化或业务流程外包的效果。	饭店的服务员、收银员..
业务实体	Business Entity	业务分析模型	代表由业务工人操作的重要且持久的对象；业务实体是被动的，不会自行发起交互；业务实体可能会在多个不同的业务用例实现中使用，且通常比任何单个交互的寿命都长；业务实体为参与不同业务用例实现的业务工人之间共享信息（信息流）提供了基础	票证、单据等。属于其他事物属性的任何信息本身可能都不是业务实体（注：《软件方法》强调业务实体只能是智能系统，和RUP有区别）

对业务建模和软件建模使用一套建模符号的最大优势是，产品/业务分析人员和开发人员共享一种沟通语言。方便从模型可以直接高效的转换为开发阶段的设计模型。

   3.3 业务建模的输出物

要达成上述目标，业务建模方法描述了如何评估当前组织并确定组织愿景，并以愿景为基础，在【业务用例模型】和【业务分析模型】中定义组织的流程、角色和职责。

因为仅靠目标组织的结构图不足以了解其运作方式。我们还需要业务的动态视图。业务模型提供组织结构的静态视图和组织内流程的动态视图。

• 模型类型及其关系
• 业务建模指导系统开发
• 理解业务，得出业务用例模型和业务分析模型
• 从而推导出指导系统开发的“用例模型、分析模型、设计模型和实现模型”
• 业务建模阶段输出业务用例模型和业务对象模型
• 业务用例模型（Business Use case Model）
• 业务所需功能的模型，用作识别目标组织中的角色和对外交付的价值（可交付件）
• 业务执行者（Business Actor）：代表业务环境中某人或某物所扮演的与业务相关的角色。如用户、供应商或合作伙伴等。
• 业务用例（Business Use case）：业务执行者希望通过和组织交互获得的由组织提供的价值。业务用例必须支持业务目标。目标领域中的业务流程，由业务用例和其实现来表示。建模业务用例和参与者的目的是描述客户和关联方如何做业务。呈现直接涉及客户或关联方的活动，以及间接涉及外部各方的支持或管理任务。
• 业务分析模型（Business Analysis Model，也称业务对象模型）
• 描述业务用例执行的对象模型，不对业务用例如何实现做假设
• 业务的分析模型描述了通过业务工人和业务实体交互来实现业务用例。
• 业务工人（Business Worker）：组织内部的人员所承担的角色
• 业务实体（Business Entity）：组织所管理或产生的事物
• 抽象了业务工人和业务实体需要如何关联及如何协作才能执行业务用例。

其次，也需要以下输出做为补充：

• 业务愿景（Business Vision）：建设系统的目的是什么，如何量化
• 业务规则（Business Rules）：必须遵守的政策或条件的声明
• 业务术语表（Business Glossary）：定义在项目的业务建模部分所使用的重要术语
• 有必要也可以补充业务架构文档和相关业务规范

参考 RUP 过程示例模型：

上图中，通过业务用例和业务流程，识别业务执行者和业务实体（注：Business Object Model 应用了 ECB 模式， 一种承载业务执行者和业务工人以及实体之间的活动图，Iconix 方法称之为 robustness analysis），并提炼出系统用例和分析模型。

建模、理解和改进业务非常类似于构建软件系统。可以看成一次探索的过程，其中包括确定目标和范围，通过高维框架逐步细化，通过整体视角，细节部分去不断审视，基于新的理解和洞察来更新模型，基本也是迭代完善的过程。

   3.4 业务建模实例

说了很多，通过推演一个餐厅的小例子来熟悉下业务建模流程和效果。

业务建模通过 UML 可视化业务流程，实践中我们通过用例图和序列图和输出业务模型。

下面通过餐饮行业一个小例子来探讨业务建模过程。

1.目标组织：餐饮行业类商户

    1.核心涉众：饭店老板

    2.组织结构：较简单，可以试想想，用静态结构呈现，了解各部分功能

2.组织的业务

    1.为消费者（即顾客）提供餐饮；

3.业务建模的目标

    1.改进业务流程，提高服务效率和质量（接待/上菜速度）

    2.业务用例：组织提供了哪些价值

4.业务用例：组织提供了哪些价值

5.业务现状：当前的业务活动及执行流程

某饭店现有堂食的业务流程如上，涉及多位业务工人（领位/服务/收银）及业务实体（绿色部分）；消费者消费时，需要与各类业务工人交互，涉及纸质记录、现金等，存在易出错效率低成本高等各类问题。

6.业务改进：建模改进，通过业务系统实现自动化改进业务流程

改进后的业务流程，创新的通过餐厅运营系统，以自动化的方式消除了多个业务工人，隐藏了多个业务实体。人工处理流程更简单，大幅提高效率和各方体验，由于通过饭店账号与消费者建立了联系，还可以主动营销提升回购率。接入微信支付系统则大幅提升可用的用户付款方式。

7.确认业务系统的需求：从通过改进的业务序列图，确认餐厅运营系统对外提供的价值。这些价值即系统要对外提供的能力，如预订、查阅菜单等。系统用例如图：

8.确认系统需求，进入系统分析和设计阶段。

如上一个入门级的业务建模过程，当然还有更多进一步的完善流程这里不做细致描述。但我们可以看到，通过模型即可快速进行业务流程的确认和分析，甚至对原有业务流程进行改进，找出建设系统的需求并为进一步提升组织的业务竞争力打下基础。

这样的改进场景很多，使用自动化的系统代替人工实现降本增效最终提升竞争力，如扫码点餐，滴滴打车等。

针对业务建模方法，下面的梳理提炼方便大家有个整体轮廓。

注意【业务】二字，表示不带入任何实现，仅关注业务（如业务用例..，业务分析..）。

   3.5 业务建模的工作流

以经典的 RUP 过程为例，基本的业务建模的工作流如下图（注意，与《软件方法》有区别：

我们可以选择工作流的多种路径之一，选择的路径取决于的业务建模工作的目的以及开发阶段。

1. 在第一次迭代时，需要评估组织状态并确定建模目标。再决定如何迭代
1. 描述业务现状
2. 识别和改进业务流程
3. 研究流程自动化（建立系统）
2. 如果不需要对整体业务进行建模，只关注领域模型，则走领域建模过程
3. 另外，当业务不做变更，可以通过业务建模分析的内容导出软件需求

上述核心路径描述如下：

一、业务建模（Business Modeling）

    1.描述业务现状：输出业务现状的业务用例模型、业务分析模型

        1.评估目标组织，识别业务目标（Goal）

• 组织结构：组织的静态结构与职责分工
• 确认业务目标：定义了要达成可持续竞争地位必须做到什么，可以按组织结构分解

        2.了解组织当前的流程和结构

• 找出业务执行者：从与业务交互的任何个人、团队、组织，公司中找
• 找出业务用例：从业务执行者从业务中获得的价值来找
• 找出业务工人：组织内的角色（人或系统），其履行相应的角色
• 找出业务实体：组织内业务工人处理的重要且持久的信息
• 收集公共业务名词：项目早期就通用业务术语达成一致非常重要
• 制定业务规则：规则的来源有些是法规强加，有些是业务执行的标准

        3.细化业务建模的目标

• 界定业务建模工作：面向整个组织，还是业务流程的子集
• 制定组织愿景，识别涉众：要解决什么问题，交付的业务系统涉及哪些相关方
• 确定业务建模目标：涉及不同的范围，包括：确认组织结构，输出领域模型，为业务构建系统，建立通用业务模型，构建新业务，业务改造。选择其中一种。

    2.找出业务改进：以现状的业务模型为起点对业务流程改进或重新思考

        1.识别业务流程及优先级

• 明确术语、确定支持业务战略的业务目标
• 输出业务用例模型
• 确定各业务用例的优先级：寻找支持最重要业务目标的业务用例

        2.完善业务流程定义：详细说明业务流程并描述其如何支持业务目标

        3.设计业务流程实现：描述如何在业务对象模型中根据协作对象（业务工人和业务实体的实例）实现特定业务用例

        4.细化角色和职责：详细说明业务实体、业务工人和业务事件，并验证业务建模的结果是否符合涉众的业务视角

    3.研究流程的自动化：确认流程中哪些部分可以并应该自动化

        1.三类自动化方式

• 缩短用例交付时间：提高现有工作方式的效率，但工作方式没变
• 重新组织或排序业务流程的活动：对业务用例做创新型改进，改变现有工作方式
• 监视、控制和改进工作方式

        2.理解如何让软件系统满足组织需求

        3.定义自动化需求：导出目标要建设的软件系统的软件需求

• 二、领域建模（Domain Modeling）：
• 识别业务领域中的概念，提供对业务运营和环境中的概念的共同一致的理解。
• 识别业务领域中的所有产出和可交付成果。

上述的简要流程每一步都有具体的定义，涉及内容很广，这里不做详细描述。

总而言之，业务建模可以提炼为以下几步：选定组织，了解业务，描述业务现状，改进业务；这里需要的是让组织提供的价值更大。

上面看到业务建模输出的模型有两种：业务用例模型与业务分析模型（业务对象模型）。而上述的领域建模是业务建模中的“描述业务现状”的精简版，只识别“业务实体”（注意，此处的“领域模型”是业务级别的分析模型，非业务流程，也非 DDD 的领域模型）。

另外要注意的是，需要让每个业务实体及使用到的任何业务术语都定义到业务术语表中，并且在业务模型中提炼业务规则（大部分业务规则都是结构约束）；过程中，拉通团队检查业务实体并达成共识。否则无法达成领域建模的目的。

   3.6 领域建模

在上述建模工作流中，领域建模是业务建模的一部分，也可以独立进行。但对于领域模型本身，业界有很多理解。我们追根溯源来整体看看领域建模。

“A domain model captures the most important types of objects in the context of the business. The domain model represents the 'things' that exist or events that transpire in the business environment." -- Ivar Jacobson.

领域建模（Domain Modeling）中的“Domain”指问题域，“Domain Modeling”则是一种将现实世界中问题域边界内的业务概念、规则和关系抽象为软件模型的方法。领域建模特指面向特定问题域按关注点构建抽象模型的过程，最终输出呈现重要概念框架的领域模型。

领域建模最早起源于数据建模（Data Modeling）并伴随面向对象分析与设计（Object-Oriented Analysis and Design，OOAD）而发展，其演变过程也是开发方法发展的过程：

1. 80年代，数据建模：是一种以数据为中心的建模方法，关注于数据的结构和关系。在数据建模阶段，模型主要关注实体、属性和实体之间的关系，通常使用实体-关系图（Peter Chen/1977）来表示。然而，数据建模方法过于关注数据结构，而忽略了业务逻辑和行为。
2. 90年代，面向对象分析与设计：OOAD 方法克服了数据建模和结构化分析与设计的局限性，将现实世界中的业务概念、规则和关系抽象为对象、属性、方法和关系。面向对象分析与设计方法强调封装、继承和多态等面向对象的特性，以实现模型的可重用性、可扩展性和可维护性。通常使用统一建模语言（UML）来表示面向对象的模型。
3. 2000年后，领域驱动设计：DDD 是在 OOAD 的基础上发展起来的一种设计方法。它关注于业务领域的概念、规则和关系，将现实世界中的业务问题抽象为软件模型。领域驱动设计（Domain-Driven Design，DDD）方法提供一系列模式来帮助提炼领域模型，包括实体、值对象、聚合根、领域事件和领域服务等。

以下领域建模（Domain Model）的出处和解释，做个汇总：

作者	出处	年代	异同
Craig Larman	Applying UML and Patterns-An Introduction to Object-Oriented Analysis and Design and the Unified Process	2002	对领域内的概念类或现实世界中对象的可视化表示，也称概念模型、领域对象模型和分析对象模型
Martin Fowler	Patterns of Enterprise Application Architecture	2002	是solution space的领域层的模型对象，即系统模型
Eric Evans	Domain Driven Design-Tackling Complexity in the Heart of Software	2003	不再将分析模型和程序设计分离开，而是寻求一种能满足这两方面的单一模型。因此DDD的模型既是领域模型，又是系统模型。同时，通用语言也可以算作领域模型的一部分。
Vaughn Vernon	Implementing Domain-Driven Design	2013	领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义

如上，业界是面向不同问题来探讨模型的抽象。因此，在不同领域背景下，模型只要能表征当前问题域中的重要概念，促进团队统一认知领域知识就能够成为领域模型（即：针对具体领域的模型）如：

• 在数据建模方法中，领域模型使用的实体关系模型（Entity-Relation Model）来承载
• 在OOAD方法中，领域模型应用分析模型（Analysis Model/Object Model）来承载
• 在 DDD 方法中，领域模型不局限于表达形式，核心是问题域中被抽象的知识和呈现要表达的思想，可以是图也可以是代码（源于 Eric Evans）。

在我们的实践中，"领域建模=领域知识+建模方法"，输出【领域模型】（Domain Model）。

所以，领域建模是一系列面向问题域的抽象建模活动，在团队内按一致的方法呈现即可称为领域模型。可见，领域建模方法是一种用做发现领域知识的设计思维。其所构建的模型，希望的是对某个有边界的领域的一个客观抽象，用于反映领域内用户需求的本质，只反应我们所关注的部分，且只反应业务，和技术无关。

在我们实践的过程中，为了可视而通常用类图表达，而且我们发现它带来更多的价值和收益：

• 面向问题域呈现概念框架，帮助思考：做为交流工具，共享知识与信息
• 解决需求和设计意图中的岐义：为关键概念和系统名词建立文档，统一理解
• 控制复杂度，为实现做指导：防止需求和最终代码实现走样
• 沉淀领域知识：模型可以被重用，模型可以被积累
• 支持在模型级别做验证：快速应对和响应需求变化

在支付团队的实际业务分析和软件系统构建过程中，领域建模活动跟随着开发周期进行，模型在过程中不断细化改进，可以贯穿从需求（概念）阶段，贯穿分析（分析类图）设计阶段（设计类图）。如下图：

因此，在支付业务的领域建模活动中，会涉及不同阶段的多种模型，通过静态建模和动态建模的相互完善和验证，并实现领域知识提炼和业务规则沉淀。相关活动大致如下：

阶段	问题域	领域建模涉及的模型	模型类型	建模过程涉及的工具
需求	抽取名词，理解和统一业务术语和概念	概念模型	静态	类图
需求/分析	识别实体和实体关系、实体属性	概念模型	静态	类图
分析	实体的类化/泛化/去泛化/提炼约束规则/切分边界/完善属性	分析模型	静态	类图
分析/设计	为实体分配职责，识别行为/补充实体动态行为	分析模型	动态	类图/序列图
分析/设计	描述实体生命周期/提炼事件	设计模型	动态	状态图
设计	实体间约束关系的知识域提炼/实体行为完善/聚合划分	设计模型	静态	类图
设计	实体到数据对象的映射/实体主键/外键/索引	数据模型	静态	ER图

总之，领域建模活动涉及需求/分析/设计多个阶段，从【概念类图】演化到【分析类图】再细化为【设计类图】。设计类图如通过详细的类化和信息补充，可以直接映射为实现阶段的代码中的类（class），应对要持久化的信息，则可以转换为数据存储层的数据库表。

   3.6.1 领域建模实例

为了方便理解，回到我们前面餐厅的小例子，其领域模型在概念阶段，按关注的堂食业务梳理如下概念/名词：

可以看到，餐厅运营这个业务领域中，需要多种角色保证餐厅的有效运作。如果从改进和降本提效的角度看，信息系统可以提供大量改进。实际上在上述模型中还可以补充更多的信息，以发现和优化业务场景下关于效率和成本的内容。

进一步补充实体属性，如下图：

再进一步处理下，需要在上菜及出菜上分别管理，方便事后核对，如下图：

事实上，在更大的同类企业中，还有更多的涉及各环节的流程和信息（如采购，财务..），在这样的模型呈现出来之后，业务系统开发团队将能更好的从全局来优化和设计信息系统，聚焦改进点（如将人工用系统自动化替代），能更好的为目标组织降本增效提升竞争力。

通过流程改进，交付的目标系统实现对人工的优化，快速将思路简化后如下图。业务实体信息化后，由业务系统管理并组成了系统本身：

再进一步按目标业务系统进行抽象如下，我们提炼出顾客体系，增强顾客联系：

我们可以提炼出多个聚合，通过聚合管理一致性边界。同时对部分实体，有必要的话也可以通过状态机描述其状态迁移过程，以明确状态管理机制。如下，点菜单的状态图。

通过一系列建模，我们可以更直观的映射到实现过程，方便对齐需求和业务目标。

这样，当运营系统（即业务系统）交付后，封装了人工处理流程，将业务实体由物流转为信息流，并实现自动化。当然，如果有机器人厨师，则可以成为全自动餐厅。

上述小例子主要有于呈现建模的价值，以及让团队对目标业务领域进行快速沟通。可能有一些不足或者不同的理解，也没有展示继续构建的数据模型，有想法的同事可以在 Xwatt 项目里创建自己的思想试验。在工具化后可以不断进行迭代达成团队理想的效果即可。不过，从一个小型餐厅如果深挖也有大大优化空间可以看出，大型的企业/组织背后涉及的复杂业务流程，其背后同样可能可以找出巨大的优化空间。这就是业务建模的巨大价值。

针对 RUP 过程中的业务建模方法，国内书籍《软件方法》也给出了相应方法沉淀，其中对流程改进的模式提炼相应指导方法总结为三点：

• 物流转信息流：观察物的流动，提炼物背后承载的信息
• 改善信息流转：把协作工作改为由一个软件系统来完成，多次人的协作优化为一次和系统的协作
• 封装领域逻辑：提炼人工封装的领域逻辑，改为封装到软件系统中去，用软件系统代替人

本文追根溯源去理解了业务建模，相关细节欢迎大家进一步论证。

   3.7 小结

业务建模是一个体系化的主题，不同的场景有其合适的用法。通常也不建议对每个项目都进行业务建模。只有当有更多角色直接参与使用该系统，并有更多不同业务信息由该系统处理时，业务建模才会增加更多价值。

例如，纯技术领域的问题中，与业务（Business）无关，可以无须业务建模，你的代码和数据结构就是你的模型抽象；例如，如果只是在现有业务系统的接入层网关中添加一项功能，则不会考虑业务建模，因为这不会从根本上改变用户/组织原本期望的功能，它仍是网关。另一方面，如果您正在构建一个全新的订单系统来支持支付业务的解决方案，则业务建模对于了解该新系统将如何影响相关业务是很有价值的。因为这个领域流程很复杂，需要定制解决方案。

我们上述的内容，核心针对业务开发团队如何快速理解业务，从业务中梳理需求和提炼领域知识探讨了相关的方法实践。

04

总结

回顾软件开发行业，业务建模方法随着 IT 系统融入商业领域而蓬勃发展，因为在原有商业领域中通过信息系统对原有业务流程实施自动化改进能提供巨大的增益，这个过程和方法的应用能力，也形成了行业咨询面向业务领域提供业务再造/解决方案的核心竞争力。

业务建模相对其它方法论有完整的理论基础（OOAD）和支撑工具，其各环节的应用在面向行业深度定制解决方案时发挥价值（如金融业核心业务系统的解决方案）。

其后，在互联网巨浪中快速爆发的工具型产品，推动了以面向代码的社区型敏捷开发方法的流行，尤其是在数据建模由 ER 模式转向 NoSQL，而这个过程中面向业务领域的开发方法，相对在互联网社区的影响力在减弱。

但当复杂业务系统再次由线下融入到线上之后，我们可以看到相关的方法论又再次进入视野，比如电商、比如物流，比如支付、金融等等。但随着行业竞争的加剧相关业务分析方法也在逐步演化，出现了一些不同的简化的建模方法，如 Aglie Modeling。

业务建模的价值在于，通过一场思想实验让团队以相对低成本、轻量的方式真实的还原业务流程；通过抽象模型提炼业务的核心领域知识以还原业务本质 ，提升团队对业务领域一致和深入的理解，来促进业务和技术更好的映射。

业务建模过程，帮助我们理解构建的业务系统背后所服务的目标组织（客户），理解其对业务系统功能的底层诉求，理解用户使用我们的业务系统/产品/服务的驱动因素。这些因素可能是降低成本、提高质量或缩短产品上市时间等目标。我们能通过业务建模来定位问题或找出改进的机会，并在建模这种轻量的活动中完成对业务改进的验证。

流行在变，但经典永存。业务建模所融入的 OO 方法/领域建模方法/业务流程改进方法，仍在为业务开发带来的有力竞争力。当今 LLM 再次为软件开发行业掀起巨浪时，作为 Prompt Engineering 背后的本质也是“如何理解业务并结构化的陈述业务需求”，这与业务建模方法为业务开发赋予的理解问题域的能力正好契合，“声明式的方法+结构化抽象并逐步分解问题”的思维不会过时，AI 时代甚至有机会赋予业务开发新价值。

05

附录

附录1

RUP 过程中的业务序列图，业务实体呈现出来（与一些方法的表示法有差异)，但个人认为 RUP 更好表达业务现状,因为目标组织始终存在人工流程和非智能系统(业务工人在处理业务用例时，仍存在重要的要处理和使用的重要且有价值的“事物”)，这类事物在 RUP 过程的方法中需要被建模为业务实体。

附录2

业务建模的 ECB 模式，经查最早由 Objectory 方法合入 RUP 过程（Ratinal Unified Process）。

参考资料

• IBM / Rational Software 《Business Modeling with the UML and Rational Suite Analyst Studio》

• Philippe Kruchten 《The Rational Unified Process-An Introduction-Third Editon》

• Grady Booch 《Object-Oriented Analysis And Design with Application Third Edition》

• Bernd Bruegge 《Object-Oriented Software Engineering》

• Ivar Jacobson 《Object-Oriented Software Engineering-A Use Case Driven Approach》

• Craig Larman 《Applying UML and Patterns –An Introduction to Object-Oriented Analysis and Design and the Unified Process》

• Martin Fowler《Patterns of Enterprise Application Architecture》

• Eric Evans 《Domain Driven Design - Tackling Complexity in the Heart of Software》

• Vaughn Vernon 《Implementing Domain-Driven Design》

• Peter Chen 《The entity-relationship model : toward a unified view of data》

• 潘加宇《软件方法》

-End-

原创作者｜stanleyluo

你是在什么时候编程能力开始突飞猛进的，为什么？欢迎评论分享。我们将选取1则优质的评论，送出腾讯Q哥公仔1个（见下图）。2月18日中午12点开奖。

📢📢欢迎加入腾讯云开发者社群，享前沿资讯、大咖干货，找兴趣搭子，交同城好友，更有鹅厂招聘机会、限量周边好礼等你来~

（长按图片立即扫码）