许多不在中国的人或许从来没听说过微信，或者以为只不过是即时通信应用 WhatsApp 或者社交媒体巨人 Facebook 的中国版。而对于在中国的人来说，微信远远不止于此。毫不夸张地说，微信是人们日常生活不可或缺的一部分。
微信，于 2010 年十月诞生在中国南部的腾讯广州研发中心。后来，它成长为中国最受欢迎的移动应用，月活跃用户数超过 10 亿，大家用它聊天、玩游戏、购物、阅读新闻、吃饭付账，还能分享自己的想法以及招聘。如今，你也可以通过微信预约医生，或者在社区法院预约离婚的时间。
年仅七岁的微信也为它背后的公司——腾讯控股，奠定了基础，使之成为中国最有影响力的公司之一，并吸引了全球投资者的目光。从 2011 年 1 月微信上线起，腾讯的市场价值已经翻了十倍。
但是，腾讯已经遇到了发展的阻力。与今年一月的高峰期 476.6 港币相比，截止 8 月 15 日，腾讯的股价跌到了 336 港币，下跌幅度达 29%，相当于市值蒸发了 1700 亿美元。即使在暴跌之前，一些评论家也被问及腾讯是否“失去了梦想”，因为它开始关注投资的增长，而不像以前那样关注创新了。
在周三收盘后，腾讯发布了第二季度财报，其中由于游戏和投资相关的收入下降，导致利润下跌了 2%。净收入在 6 月 30 日季度结束时下跌至 179 亿人民币（合 26 亿美元），而彭博社编译的 12 份分析师预测的平均值为 193 亿人民币。销售额为 737 亿人民币，也没有达到分析的预期。
而在美国，与腾讯相当的 Facebook 的日活跃用户（DAU）为 14.7 亿，月活跃用户（MAU）为 22.3 亿，在 7 月份发布第二季度财报后，由于用户增长速度下降到了 2011 年以来的最低点，使得股价下跌了大约 20 个百分点。
但是，腾讯在将微信的庞大用户群转化为金钱的方面依然刚刚起步。
据腾讯的首席战略官 James Gordon Mitchell 在五月份与分析师们的一次电话会议上说，为避免大量广告影响用户的时间线，微信的社交平台“朋友圈”上每天只允许出现最多两条广告，“与国际同行相比这是极端保守的策略”。
Jefferies 的分析师 KarenChan 在 7 月份的一份研究报告中写到，“随着广告定位能力的增长、广告量的增加和对新广告格式的支持，基于社交媒体的广告将会有大幅度的增长，而其中腾讯……将成为最主要的受益者。”
其他分析师也对微信的前景持乐观态度。“（微信的用户数）尚未触及天花板，但我认为这总有一天会发生，”独立微信咨询机构 China Channel 的管理主任 Matthew Brennan 说，“但微信在广告以及现在的小程序方面依然有很大的增长空间。”
小程序指的是能直接在微信界面中运行的、通常小于 10MB 的应用程序。小程序能提供迅捷的访问速度，因为用户无需从应用商店中下载，可以直接从微信中运行。这项技术可以允许微信上的各种平台提供多种服务，使之成为“超级应用”，给全球最大的手机市场的消费者们提供更大的便利。
小程序的目标是将用户留在微信的生态系统中，而这时正是短视频应用崛起的时代。根据互联网数据服务提供商 QuestMobile 七月份提供的数据，与去年同比，今年六月份移动用户在即时通信应用上花费的时间从 36% 下降到30.2%，而在短视频应用上花费的时间从 2% 提高到 8.8%。
但是，小程序只是微信的一系列创新中最新的一个而已。
尽管腾讯的旗舰消息服务 QQ 曾经在中国占据了垄断地位，但腾讯的创始人兼总裁兼 CEO 马化腾并没有放弃努力。在 2010 年，随着苹果的 iPhone 的流行，他就敏锐地察觉到了桌面互联网向移动互联网不可避免的转变。马化腾知道移动端的即时通信应用才是未来的重点。
70 天开发的微信，也曾经历坎坷
2010 年，QQ 手机邮箱的负责人张小龙带领一个不到十人的团队用了不足 70 天的时间开发了微信的第一个版本，从与公司内部另外两个从事微信项目的团队的竞争中脱颖而出。张小龙创立的 Foxmail 于 2005 年被腾讯收购，他也随之加入腾讯，成为了 QQ 手机邮箱的负责人。
腾讯控股总裁刘炽平在 2011 年的一次电话会议中说，“微信在腾讯的战略中是个极端重要的平台，它能在从桌面向移动端过渡的过程中，帮助腾讯维持并发展在社交领域的领先地位。”
腾讯向本文提供了有关微信开发的最新消息，但包括张小龙在内的高管们并没有接受本文的采访。为得到有关微信开发历史的信息，南华早报回溯了到 2010 年为止的所有电话会议的记录、文件和公开讲话。
微信的第一个版本只允许用户发送文本和照片。第一版并没有引起太大反响，因为当时许多即时通信软件，如中国移动的飞信、小米的米聊等已经占据了一定市场。
七年前，一名用户在微信 iOS 版的页面上给微信打了一星，并评论道：“它不能像飞信那样给电话号码发消息，也没有 QQ 的功能，那要这个应用有什么用？”
微信团队的转折点发生在 2011 年 5 月，当时微信发布了语音消息功能，用户可以像使用对讲机一样使用。日用户增长数量从 10000 增加到了 60000。
马化腾在 2016 年于清华大学的一次讲话中提到，“语音消息（功能）将不习惯打字的上年纪的商务人士变成了微信的用户。”
微信迅速发展，增加了许多新功能，如“摇一摇”，可以随机地在同时使用该功能的用户间建立联系，还有“漂流瓶”，可以把消息发送给随机的用户。
2011 年 7 月，微信增加了基于位置的服务“附近的人”，可以让用户找到附近的陌生人。据张小龙说，这个功能“改变了游戏规则”，将用户日增长量提高到了 10 万。
“摇一摇、漂流瓶和附近的人都诞生在了正确的时候，给不同的人群提供了不同的访问方式。”微信的前员工 Lu Shushen 在他的微信账号里的一篇文章中讨论陌生人社交网络时说。
到了 2012 年 3 月，微信的注册用户量超过了一亿，此时距离微信发布仅仅 433 天。
微信用户随着中国的智能手机用户增长而增长。2010 年，当时微信还只是个研究项目，中国的智能手机销售量只有 3610 万台。到了 2011 年微信正式发布时，这个数字增长到了 9060 万，到 2012 年更是直冲 2 亿 1420 万。
但微信的增长速度比这还要快，逐渐地把其他竞争者抛到了身后。例如，飞信一直拒绝非中国移动的用户使用其消息服务，而米聊的用户体验一直不稳定。
据 China Channel 的 Brennan 回忆，微信在海外的最大竞争者 WhatsApp 当时在中国市场上也能使用，但由于缺乏本地化，也缺乏市场推广，因而错失良机。
从 0 到 10 亿用户，微信的发展史
2011 年 1 月 14 日：发布微信在中国大陆发布。第一个版本只有基本的文本通信功能。
2011 年 5 月：语音微信增加了语音功能，允许用户发送 60 秒以下的语音消息。
2011 年 10 月：连接微信增加了“摇一摇”和“漂流瓶”功能，使用户可以联系到陌生人。
2012 年 3 月：一亿微信的注册用户量超过一亿，距离发布只有 433 天。
2012 年 5 月：朋友圈微信增加了社交平台“朋友圈”，使用户能够与朋友分享日常生活。
2012 年 9 月：两亿微信的注册用户量超过两亿。
2013 年 1 月：三亿微信注册用户量达到三亿。
2013 年 8 月：新功能微信增加了公众号、微信支付、表情包商店和游戏中心。
国际增长微信的海外注册用户量达到一亿。
2014 年 1 月：红包微信上线“红包”功能。
2014 年 10 月：视频朋友圈增加了分享短视频的功能。
2015 年 5 月：健身记录微信运动功能上线，能够记录用户每天的步数。
2016 年 1 月：小程序微信的创始人张小龙公布，他的团队正在测试小程序功能，可以在服务中添加类似应用的功能。
2017 年 1 月：超级应用状态微信的小程序上线。
2018 年 2 月：10 亿用户微信在中国和全世界范围内地总计月活跃用户量超过了10亿。
随着朋友圈、公众号（类似于博客，供品牌和内容提供商营销用）和游戏平台的发布，微信也发展成了混合型社交网络。
微信在 2013 年加入了支付功能。一段时间内，微信支付仅能用于购买游戏、虚拟物品和手机充值等服务。但在 2013 年公众号功能上线时，腾讯的管理层希望该功能可以让微信成为全功能的平台。
任何用户都可以建立公众号，像博客一样向关注者发送消息和文章，不过品牌和服务提供商也可以使用该功能给客户提供服务。今天，用户可以在公众号上做许多事情，如购买产品、订餐或者预定医生等。
但是，尽管微信支付启动时的发展缓慢，但它将给整个行业带来巨大的变革。
在 2014 年春节前夕，腾讯的联合创始人张志东指定了一名团队成员负责改进腾讯公司给员工发红包的方式。其结果就是微信红包功能，可以让人们给朋友发送“虚拟”的金钱。
微信红包在 2014 年春节期间一夜走红，800 万中国用户收到了超过 4000 万个红包，被阿里巴巴创始人马云戏称为“珍珠港事件”。用户开始将银行账号绑定到微信手机钱包上，从而使得微信拥有了与支付宝竞争的能力。支付宝是当时已经成熟的移动支付服务，由南华早报的母公司阿里巴巴集团创立。
2018 年除夕，6 亿 8800 人使用了微信红包功能。
回到微信小程序的话题。小程序无需下载就能增强微信生态系统的功能，可以用来在微信内增强用户忠诚度（即用户粘度）。
腾讯的刘炽平在 2017 年曾表示：“我们把小程序看作公众号系统的增强，可以将线下服务和线上用户联系起来。”
小程序的概念并没有受到太多关注，直到 2018 年 1 月，一个于前一年 12 月发布到小游戏“
跳一跳
”达到了 10 亿日活跃用户。“我们这一年经历了许多起起落落，但总的来说，我们认为我们达到了最初的目标。”张志东在 1 月份接受人民日报采访时表示。
到了 2018 年第二季度，微信小程序达到了一百万，六月份小程序用户超过了 6 亿。
中国区的 Brennan 说：“小程序的创意给腾讯打开了许多大门。比如通过广告和支付变现的能力……通过允许（腾讯）在生态系统中孵化并加速各种业务，特别是电子商务业务。”
原文：
译者：弯月，责编：屠敏
微信小程序开发指南
副标题：从入门到精通，掌握小程序开发的关键技巧
随着移动互联网的快速发展，微信小程序作为一种全新的应用形式，正逐渐成为开发者和企业关注的焦点。本文将为您详细介绍微信小程序开发的相关知识和技巧，帮助您快速入门并掌握小程序开发的要点。
一、什么是微信小程序？
微信小程序是一种无需下载安装即可使用的应用程序，用户可以直接在微信中打开并使用。小程序具有轻量级、易传播、无需安装等特点，广受用户喜爱。开发者可以通过微信官方提供的开发工具进行开发，并上传至微信平台进行发布。
二、如何进行小程序开发？
小程序开发主要使用微信小程序开发工具，开发语言为JavaScript。开发者需要先了解小程序的基本框架和组件，以及如何进行页面布局和交互设计。同时，开发者还需要熟悉小程序的生命周期和事件处理机制，以便更好地控制程序流程和逻辑。
三、小程序开发的技巧和注意事项
在进行小程序开发时，开发者需要注意以下几点：1. 页面设计要简洁清晰，避免过多的功能和信息堆砌；2. 优化页面加载速度，减少不必要的请求和资源加载；3. 合理使用小程序的API和组件，提高程序的性能和用户体验；4. 注意小程序的安全性和数据保护，避免出现漏洞和信息泄露。
四、小程序的推广和营销策略
在开发完成后，开发者还需要考虑如何推广和营销自己的小程序。可以通过微信朋友圈、公众号等渠道进行推广，同时结合社交分享和口碑营销，吸引更多用户使用和关注。此外，可以通过小程序内的广告和活动促销等方式，增加用户粘性和活跃度。
五、小程序的未来发展趋势和展望
随着技术的不断发展和用户需求的变化，微信小程序也将不断更新和升级。未来，小程序可能会更加智能化和个性化，为用户提供更优质的服务和体验。因此，作为开发者和企业，需要不断学习和掌握最新的技术和趋势，以适应市场的变化和需求的提升。
通过本文的介绍，相信您已经对微信小程序开发有了更深入的了解，希望能够帮助您更好地掌握小程序开发的技巧和要点，实现自己的开发目标和商业价值。祝您在小程序开发的路上越走越远，取得更大的成就！
作者：stanley
拔开迷雾，直达本质，万字长文带你搞透业务开发。业务是什么，如何挖掘价值？本文从几方面来探讨做好业务开发的思考，第一篇谈业务，抛砖引玉，欢迎探讨改进。
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》潘加宇《软件方法》