拔开迷雾，直达实质，万字长文带你搞透业务开拓。
业务是什么，如何挖掘代价？本文从几方面来磋商做好业务开拓的思考，第一篇谈业务，抛砖引玉，欢迎磋商改进。

1-业务问题关于业务

业务（Business）：在大多数情形下，表示一个组织、公司或个人所从事的商业活动、做事或事情，有相应的流程和规则。
可以理解为达成某种目的（如盈利、增长、知足客户需求等）所进行的各种活动，涉及到如何创建代价、知足需求和实现目标。
业务干系活动所涉及的问题范围，即问题域（Business Domain），问题域常日也便是公司为其客户供应的做事。
以支付业务为例：

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

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

关于产品

产品，常日是指对应的业务背景下为干系问题域供应的办理方案，即为用户/目标组织所供应的系统或做事。
针对于出业务，市场上面向用户供应了各种类型的产品，如面向线下收单的各种办理方案，到现在的第三方支付平台“微信支付”、“支付宝”上面向业务诉求和场景所供应支付产品。
从业务问题域侧重点的差异可以看到产品形态的差异。

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

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

关于系统

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

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

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

在非科技行业的各种公司中，组织的业务方面与现有信息技能之间存在差距。
缩小组织和技能之间的差距非常主要，由于在当今充满活力和竞争的市场中，公司必须得向客户供应更好的产品/做事才能生存。
而信息系统让公司和组织，乃至行业得以大幅提效。
这里的信息系统，即面向业务改进所培植的软件系统，即业务开拓所交付的“业务系统”。

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

2-开拓寻衅

业务便是为客户供应代价以获牟利润。
经营企业便是有能力预判并做出决策，而信息是决策质量最主要的决定成分。
信息系统的设计必须确保所供应的信息及时、准确且充分干系。
只有当我们理解做出这些决策的背景时，我们才能确保信息系统以这种办法支持业务决策。

业务开拓，冠以“业务”前缀，要的是在技能通识的根本上，更要熟习业务。
是另一个维度的全栈（业务+技能）能力。
业务开拓团队，要承接并交付出“好”的业务系统，寻衅在两点：

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

这也是大多数团队所面临的寻衅：

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

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

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

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

业务开拓的寻衅，这里磋商两点：1-理解业务，2-融入业务视角来设计/构建系统。
注：本篇先磋商第一部分。
第二部分不才一篇连续。

理解业务

理解业务，须要以全面透彻的视角看业务，理解涉众诉求、利益关系以及代价链。
做为业务开拓，读/写代码、转换用户视角利用产品功能外，要从行业发展过程和法规管控缘故原由去理解业务。
对付技能要承载的业务，要跳出单一代码视角，从两种视角拆开看：

问题空间（Problem）：即业务的问题域，磋商和关注的是有什么问题要办理，或者存在什么痛点要肃清，也即需求；解空间（Solution）：也称办理方案域，考虑有哪些方案去办理这些问题；终极用哪个方案做到了，称为实现。
区分这两部分的意义在于：提问题比办理问题更主要。
提对问题，才能找对方向，给出多种方案，才能掌握风险防止南辕北辙。

在事情过程中，须要将两方面分开谈论，而不是稠浊在一起。
这能帮助我们把把稳力放到要聚焦的问题本身，去关注用户想要什么（Want）、痛在哪里，再去列举可能的办理方案（How）。
反之，轻则只理解表面上的交互流程，导致面向UI开拓 （例如，将领域逻辑和业务规则直接写到UI层或者写成Transaction Script，导致实则是该当被领域工具管控的业务规则被分散到各处而失落去掩护性）；重则方向性缺点，半途而废。

动手之前，通过面向业务提好的问题，能帮助我们创造业务实质、覆盖全局且不留去世角。
初识业务，或者成熟业务上扩展出新需求，须要主动思考：

这个业务，现状是什么样的，为谁做事？这个业务，全景是若何的？高下游、互助方涉及哪些内容？他们是怎么互助的？这个业务，最核心的代价在哪里？利润从何而来？这个业务，最主要的待办理的问题是什么？这个业务，当前市情上有哪些办理方案，这些产品因此什么思路设计的？...

在磋商上述问题之后，还可进一步运用熟习业务，比如：

团队虽面向需求切入，在须要在过程中提炼总结并沉淀领域知识，提升对业务理解力和敏感度。
一边提问一边参与项目实践，类似利用（Problem-Based Learning+Project-Based Learning）结合的学习模式，能快速帮助团队提升对业务的觉得。

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

做对需求

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

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

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

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

相信大型、跨多团队协作培植和运营的长生命周期业务系统会有同感。
对付支付业务，在为不同行业的企业/商家供应有竞争力的在支付/资金办理方案过程中，更感想熏染到透过产品表面形态穿透业务本身的意义和代价。
此处的不断实践，我们将上述寻衅的办理方案落脚于业务建模方法上。
来一起看看：业务建模。

3-业务建模

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

模型为我们阐明了某事物或某事宜的某些方面或某些不雅观点。
为了实现这样的通用目的，模型紧张分为静态和动态两种：静态模型呈现构造，动态模型呈现事宜流。

建模（Modeling），是一种处理繁芜性的手段。
建模意味着构建一个别系的抽象，通过抽象模型关注感兴趣的方面并忽略不干系的细节。
建模使我们能够通过分而治之的方法处理繁芜性：对付我们想要办理的每种类型的问题，我们构建一个仅关注与问题干系的问题的模型。
一样平常来说，建模的重点是建立一个足够大略、可以让人完备节制的模型。

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

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

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

业务建模的目标理解目标组织的构造及运行机制理解目标组织中当前存在的问题并找出改进的潜力（放大代价！
）评估组织变革带来的影响确保客户、终极用户和开拓职员就目标组织达成共识导出支持目标组织所需的软件系统需求理解将交付的软件系统如何在目标组织中事情

业务建模描述了如何评估当前组织并制订新组织的愿景。
然后，以该愿景为根本，在业务用例模型和业务剖析模型中定义该组织的流程、角色和职责。
可见，业务建模很好的应对了我们在做需求时所提到的寻衅：理解业务，做对需求乃至洞察需求。

业务建模的技能

业务建模是一种技能，建模措辞常见的有UML和BPMN等，基于通识我们紧张利用了UML。
业务建模的UML常用符号如下：

在我们的实践中，多采取序列图来梳理业务流程（实例中的图示觉得很好理解，对吧)。
干系业务建模的符号解释如下：

对业务建模和软件建模利用一套建模符号的最大上风是，产品/业务剖析职员和开拓职员共享一种沟通措辞。
方便从模型可以直接高效的转换为开拓阶段的设计模型。

业务建模的输出物

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

由于仅靠目标组织的构造图不敷以理解其运作办法。
我们还须要业务的动态视图。
业务模型供应组织构造的静态视图和组织内流程的动态视图。

模型类型及其关系理解业务，得出业务用例模型和业务剖析模型从而推导出辅导系统开拓的“用例模型、剖析模型、设计模型和实现模型”业务建模辅导系统开拓业务建模阶段输出业务用例模型和业务工具模型业务用例模型（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)，并提炼出系统用例和剖析模型。

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

业务建模实例

说了很多，通过推演一个餐厅的小例子来熟习下业务建模流程和效果。
业务建模通过UML可视化业务流程，实践中我们通过用例图和序列图和输出业务模型。
下面通过餐饮行业一个小例子来磋商业务建模过程。

目标组织：餐饮行业类商户核心涉众：饭店老板组织构造：较大略，可以试想想，用静态构造呈现，理解各部分功能组织的业务为消费者（即顾客）供应餐饮；业务建模的目标改进业务流程，提高做事效率和质量（接待/上菜速率） 2.业务用例：组织供应了哪些代价业务用例：组织供应了哪些代价业务现状：当前的业务活动及实行流程某饭店现有堂食的业务流程如上，涉及多位业务工人（领位/做事/收银）及业务实体（绿色部分）；消费者消费时，须要与各种业务工人交互，涉及纸质记录、现金等，存在易出错效率低本钱高档各种问题。
(注:RUP/软件方法的建模方法在这一点上有规范上的差异见附录1)业务改进：建模改进，通过业务系统实现自动化改进业务流程改进后的业务流程，创新的通过餐厅运营系统，以自动化的办法肃清了多个业务工人，隐蔽了多个业务实体。
人工处理流程更大略，大幅提高效率和各方体验，由于通过饭店账号与消费者建立了联系，还可以主动营销提升回购率。
接入微信支付系统则大幅提升可用的用户付款办法。
确认业务系统的需求：从通过改进的业务序列图，确认餐厅运营系统对外供应的代价。
这些代价即系统要对外供应的能力，如预订、查阅菜单等。
系统用例如图：确认系统需求，进入系统剖析和设计阶段。

如上一个入门级的业务建模过程，当然还有更多进一步的完善流程这里不做细致描述。
但我们可以看到，通过模型即可快速进行业务流程的确认和剖析，乃至对原有业务流程进行改进，找出培植系统的需求并为进一步提升组织的业务竞争力打下根本。
这样的改进场景很多，利用自动化的系统代替人工实现降本增效终极提升竞争力，如扫码点餐，滴滴打车等。

针对业务建模方法，下面的梳理提炼方便大家有个整体轮廓。
把稳【业务】二字，表示不带入任何实现，仅关注业务（如业务用例..，业务剖析..）。

业务建模的事情流

以经典的RUP过程为例，基本的业务建模的事情流如下图（把稳，与《软件方法》有差异：

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

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

上述核心路径描述如下：

一、业务建模（Business Modeling）缩短用例交付韶光：提高现有事情办法的效率，但事情办法没变重新组织或排序业务流程的活动：对业务用例做创新型改进，改变现有事情办法监视、掌握和改进事情办法明确术语、确定支持业务计策的业务目标输出业务用例模型确定各业务用例的优先级：探求支持最主要业务目标的业务用例组织构造：组织的静态构造与职责分工确认业务目标：定义了要达成可持续竞争地位必须做到什么，可以按组织构造分解找出业务实行者：从与业务交互的任何个人、团队、组织，公司中找找出业务用例：从业务实行者从业务中得到的代价来找找出业务工人：组织内的角色（人或系统），实在行相应的角色找出业务实体：组织内业务工人处理的主要且持久的信息网络公共业务名词：项目早期就通用业务术语达成同等非常主要制订业务规则：规则的来源有些是法规强加，有些是业务实行的标准界定业务建模事情：面向全体组织，还是业务流程的子集制订组织愿景，识别涉众：要办理什么问题，交付的业务系统涉及哪些干系方确定业务建模目标：涉及不同的范围，包括：确认组织构造，输出领域模型，为业务构建系统，建立通用业务模型，构建新业务，业务改造。
选择个中一种。
三类自动化办法理解如何让软件系统知足组织需求定义自动化需求：导出目标要培植的软件系统的软件需求识别业务流程及优先级完善业务流程定义：详细解释业务流程并描述其如何支持业务目标设计业务流程实现：描述如何在业务工具模型中根据协为难刁难象（业务工人和业务实体的实例）实现特定业务用例细化角色和职责：详细解释业务实体、业务工人和业务事宜，并验证业务建模的结果是否符合涉众的业务视角评估目标组织，识别业务目标（Goal）理解组织当前的流程和构造细化业务建模的目标描述业务现状：输出业务现状的业务用例模型、业务剖析模型找出业务改进：以现状的业务模型为出发点对业务流程改进或重新思考研究流程的自动化：确认流程中哪些部分可以并该当自动化二、领域建模（Domain Modeling）：识别业务领域中的观点，供应对业务运营和环境中的观点的共同同等的理解。
识别业务领域中的所有产出和可交付成果。

上述的简要流程每一步都有详细的定义，涉及内容很广，这里不做详细描述。
总而言之，业务建模可以提炼为以下几步：选定组织，理解业务，描述业务现状，改进业务；这里须要的是让组织供应的代价更大。

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

其余要把稳的是，须要让每个业务实体及利用到的任何业务术语都定义到业务术语表中，并且在业务模型中提炼业务规则（大部分业务规则都是构造约束)；过程中，拉通团队检讨业务实体并达成共识。
否则无法达成领域建模的目的。

领域建模

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

“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）而发展，其演化过程也是开拓方法发展的过程：

80年代，数据建模：是一种以数据为中央的建模方法，关注于数据的构造和关系。
在数据建模阶段，模型紧张关注实体、属性和实体之间的关系，常日利用实体-关系图（Peter Chen/1977）来表示。
然而，数据建模方法过于关注数据构造，而忽略了业务逻辑和行为。
90年代，面向工具剖析与设计：OOAD方法战胜了数据建模和构造化剖析与设计的局限性，将现实天下中的业务观点、规则和关系抽象为工具、属性、方法和关系。
面向工具剖析与设计方法强调封装、继续和多态等面向工具的特性，以实现模型的可重用性、可扩展性和可掩护性。
常日利用统一建模措辞（UML）来表示面向工具的模型。
2000年后，领域驱动设计：DDD是在OOAD的根本上发展起来的一种设计方法。
它关注于业务领域的观点、规则和关系，将现实天下中的业务问题抽象为软件模型。
领域驱动设计（Domain-Driven Design，DDD）方法供应一系列模式来帮助提炼领域模型，包括实体、值工具、聚合根、领域事宜和领域做事等。

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

如上，业界是面向不同问题来磋商模型的抽象。
因此，在不同领域背景下，模型只要能表征当前问题域中的主要观点，促进团队统一认知领域知识就能够成为领域模型（即：针对详细领域的模型）如：

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

在我们的实践中，"领域建模=领域知识+建模方法"，输出【领域模型】（Domain Model）。
以是，领域建模是一系列面向问题域的抽象建模活动，在团队内按同等的方法呈现即可称为领域模型。
可见，领域建模方法是一种用做创造领域知识的设计思维。
其所构建的模型，希望的是对某个有边界的领域的一个客不雅观抽象，用于反响领域内用户需求的实质，只反应我们所关注的部分，且只反应业务，和技能无关。

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

面向问题域呈现观点框架，帮助思考：做为互换工具，共享知识与信息办理需求和设计意图中的岐义：为关键观点和系统名词建立文档，统一理解掌握繁芜度，为实现做辅导：防止需求和终极代码实现走样沉淀领域知识：模型可以被重用，模型可以被积累支持在模型级别做验证：快速应对和相应需求变革

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

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

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

领域建模实例

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

可以看到，餐厅运营这个业务领域中，须要多种角色担保餐厅的有效运作。
如果从改进和降本提效的角度看，信息系统可以供应大量改进。
实际上在上述模型中还可以补充更多的信息，以创造和优化业务场景下关于效率和本钱的内容。
进一步补充实体属性，如下图：

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

事实上，在更大的同类企业中，还有更多的涉及各环节的流程和信息（如采购，财务..），在这样的模型呈现出来之后，业务系统开拓团队将能更好的从全局来优化和设计信息系统，聚焦改进点（如将人工用系统自动化替代），能更好的为目标组织降本增效提升竞争力。
通过流程改进，交付的目标系统实现对人工的优化，快速将思路简化后如下图。
业务实体信息化后，由业务系统管理并组成了系统本身：

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

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

通过一系列建模，我们可以更直不雅观的映射到实现过程，方便对齐需求和业务目标。
这样，当运营系统（即业务系统)交付后，封装了人工处理流程，将业务实体由物流转为信息流，并实现自动化。
当然，如果有机器人厨师，则可以成为全自动餐厅。

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

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

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

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

小结

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

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

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

4-总结

回顾软件开拓行业，业务建模方法随着IT系统融入商业领域而发达发展，由于在原有商业领域中通过信息系统对原有业务流程履行自动化改进能供应巨大的增益，这个过程和方法的运用能力，也形成了行业咨询面向业务领域供应业务再造/办理方案的核心竞争力。
业务建模相对其它方法论有完全的理论根本（OOAD）和支撑工具，其各环节的运用在面向行业深度定制办理方案时发挥代价（如金融业核心业务系统的办理方案）。

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

但当繁芜业务系统再次由线下融入到线上之后，我们可以看到干系的方法论又再次进入视野，比如电商、比如物流，比如支付、金融等等。
但随着行业竞争的加剧干系业务剖析方法也在逐步蜕变，涌现了一些不同的简化的建模方法，如Aglie Modeling。
业务建模的代价在于，通过一场思想实验让团队以相对低本钱、轻量的办法真实的还原业务流程；通过抽象模型提炼业务的核心领域知识以还原业务实质 ，提升团队对业务领域同等和深入的理解，来促进业务和技能更好的映射。

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

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

附录

附录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》潘加宇《软件方法》