作为开发人员和架构师，我们经常困惑于业务架构，又或者如何将业务映射到微服务实现，传统模式，业务专家 BA 进行业务相关的调研分析，将需求分析说明书交付给研发团队进行后续迭代开发，而在基于云基础设施的业务敏捷创新的今天，从业务到研发再到运维，协作的越好，整体效率和应对市场变化的能力就越高，从而接受市场反馈，不断迭代验证的过程就越顺利，无论正反馈还是负反馈，都是满足客户业务迭代的“良药”，从而极大增强了团队和企业的反脆弱性。另外一个常见的挑战是，对于一个已经在运行的单体应用，如何优化改造成微服务？通常，该应用已经存在很多年，有非常多的依赖关系，没有一个超级英雄，掌握所有细节。
无论哪种情况，“业务领域专家”重新梳理业务愿景和目标，再到业务流程再造，是系统演进和改造的关键环节。
什么是业务架构？
通常业务架构不被开发人员重视，开发人员往往追求新技术，而技术是服务于业务，设计好的业务，需要做的业务领域的隔离和解耦，同时业务领域和技术架构也需要解耦。
“技术归技术，业务归业务”，这种泾渭分明的分工在数字化和云计算时代显得有点格格不入，就拿亚马逊 AWS 来说，为什么我们定义 AWS 是面向构建者、创业者和创造者的云？数字化产品是这个时代最主流的产品，而基于云服务的软件和服务交付则是如今和未来最广泛的产品开发迭代方式。
早在1987年，John Zachman就提出 ”企业架构“模型，该模型从不同的角色视角定义了“5W1H”，即”What（数据）“，”Where（网络）“，”Who（角色）“，”When（时间）“，”Why（动机）”和“How（功能）”。
企业架构通常分为业务架构和IT架构，所谓业务架构，是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF 框架详细描述了如何定义“业务架构，应用架构，技术架构，数据架构”，是流行的企业 IT 战略规划的最佳实践指引。
在 TOGAF 中，定义了业务架构的部分交付物有，组织、驱动力、角色、业务目录、流程，事件，控制等、用例图、流程图等。
所谓”业务架构“本质上是解决业务复杂性问题，将”问题域“进行思考、抽象、分解和归纳过程成业务领域模型过程，这个过程中，我们需要，（1）所有业务方对于业务目前现状（AS-IS）和未来愿景（TO-BE）有个共同的理解和愿景（2）业务交互过程的理解，一项业务往往涉及很多业务过程，比如购物车业务，涉及添加商品，删除商品，计算商品金额，清空购物车，调整商品数量等场景。
如何落地业务架构？
认识到业务架构的重要性尤其是对于开发人员而言同样重要是技术人员主动参与业务架构的第一步；那在具体项目中如何实践落地业务架构呢？
首先，开发人员要摒弃技术“细节”惯性思维，尤其不要把业务简单对照到数据库的增删改查，从宏观再到微观，比如最近涨了火热的股市，你有研究过股市业务吗？两融，北向资金，打新，竞价，印花税，注册制，限价买入，逆回购，交易撮合等等；这之后才能真正做好程序化交易，或者开发股票交易软件等数字化产品。
其次，业务架构的方法很多，比如领域建模、事件风暴、用例、四色建模等等，没有一劳永逸的“银弹”，掌握每个方法的特点，找到适合自身业务和团队的方法。
再次，纸上得来终觉浅，一定要实践，业务架构相关的理论很重要，但更重要的是实践，讲再多也不如在一个项目中实践学到的多，别犹豫，先做再说。
通常，业务架构你首先创建业务能力模型，以映射业务能力并将其与特定层次的业务实体对齐；但分类本身并不提供更广泛的限界上下文，也不能深入了解如何将功能分解为微服务，这是事件风暴可以帮助的地方。
事件风暴由 Alberto Brandolini 首创，是一种互动方式来进行域驱动设计 (DDD)的方法，主要协作对象是所涉及的业务和技术部门的领域专家；后续篇章，我将引用一个深入迭代的事件风暴示例，展示如何将其应用于您的架构工作。
什么是事件风暴？
什么是事件风暴？我们先来澄清一些关于事件风暴的常见误解。
事件风暴等同于领域驱动？
领域驱动设计是以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型，由领域模型驱动软件设计，用代码来实现该领域模型；
虽然事件风暴继承了许多领域驱动的概念（包括限界上下文和聚合），但正式的领域驱动设计可能会很复杂，需要大量的培训。而事件风暴侧重于交互式协作白板练习，让所有领域专家都参与进来。它更简单，不需要像正式的领域驱动设计那样广泛的培训。
事件风暴等同于 Design Thinking？
事件风暴和设计思维都利用交互式业务流程互动练习和白板。它们的不同之处在于，事件风暴侧重于定义微服务体系结构的分解和分类，它还侧重于业务流程中当前正在发生的事情，称为事件。设计思维分多阶段过程，包括问题定义、需求发现和基准测试、构想、原型设计和测试，它还更侧重于共情和业务痛点。
把大象装进冰箱
现在让我们深入了解事件风暴的细节，首先要了解的事情之一是捕获的关于业务域的不同类型的详细信息；这些不同类型的细节通常由不同颜色的便签贴表示。
- 事件（橙色）：是事件风暴中最重要和最广泛使用的组件，代表业务域事件和任何与业务领域域专家相关的事件，它们是以过去的时间编写的，并提供了后续分组的基础信息。
- 命令（蓝色）：这是要做某些事情的请求。它们可以来自用户或系统，也可以来自其他事件。
- 系统（粉色）：这代表业务域中涉及的系统。他们可以发出命令或接收命令以及触发事件。
- 用户（黄色）：这是参与业务过程的用户（人）。他们可以是一个人，也可以是一个部门/团队。黄色有助于显示业务流程的复杂程度，通过涉及的部门数量和来回次数来识别。
- 聚合（棕黄）：这是分组的第一级，可以被认为是一组事件操作的 “对象”。通常，它们是一个名词，当有一组事件相互依赖时可以识别。
- 读取模型（绿色）：表示可能对用户或系统作出决策至关重要的数据。这个不经常使用，但是当需要强调用户看到的数据时，它可能会有所帮助。
- 策略（灰色）：表示可能需要执行标准或规则，例如合规性策略的规则。
现在我们了解了我们希望在域中发现的不同类型的事情，让我们用一个例子来看看事件冲击的每个迭代步骤。对于我们的示例，我们将对通用电子商务网站的域进行建模。
业务愿景
我们回到 2006年，AWS 发布的第一个云数字化服务 S3 的新闻稿是怎么写的。
一句话描述 Amazon S3 是什么？
Amazon S3 以极低的成本为高可扩展、低延迟存储提供应用程序程序接口
西雅图 —（美国商业资讯）— 2006 年 3 月 14 日 — Amazon Web Services 今天宣布推出 “Amazon S3 (TM)”，这是一项简单的存储服务，它以极低的成本为软件开发人员提供高度可扩展、可靠和低延迟的数据存储基础架构。亚马逊 S3 今天可以通过 http://aws.amazon.com/s3 访问。
这段话，进一步阐述了该服务的用户对象，用户可以获得的好处和优势。
亚马逊 S3 是互联网存储。它旨在使开发人员更容易进行 大规模 Web 计算。Amazon S3 提供了一个简单的 Web 服务界面，可用于随时从 Web 上的任何位置存储和检索任意数量的数据。它允许任何开发人员访问 Amazon 用于运行自己的全球网站的高度可扩展、可靠、快速、廉价的数据存储基础设施。该服务旨在最大限度地提高规模效益，并将这些优势传递给开发人员。
有别于当时其他存储类型，Amazon S3 是“互联网”存储，随时随地访问，价格低廉，高可扩展，可靠快速，帮助开发人员更容易进行大规模 Web 应用开发。
亚马逊的逆向工作法，先写新闻稿（面向你的客户），讲清楚你发布的产品是什么？对他们有什么价值？有哪些核心功能？那些早期用户有什么样的反馈？用户体验如何？完整的新闻稿，大家可以通过文末链接进一步阅读。
因此，在进入项目团队组建，开发，测试推向市场之前，先需要整理出你聚焦那块业务，涉及的干系人和用户是谁，相比已有的方案，提供哪些独特的价值，从而整理出该“未来”产品的愿景。
当然，团队也可以利用，结构化思考的一些工具辅助输出业务愿景，比如 Melissa Perri 的 Product Strategy Canvas，下图就是一个例子：
事件风暴实操过程
步骤 #1 识别领域事件
事件风暴的第一阶段是识别领域事件。基本上，会议室里的每个人都在提事件并把它们贴在白板上。将这个阶段视为头脑风暴，因此避免在这个阶段应用任何分析或过滤，因为它只会减慢事情。
此步骤通常需要最长的时间，并且必须留出足够的时间来捕获所有基础的事件。以电商为例，一些可能的事件包括订单提交、付款处理或库存更新等。此阶段的输出示例如下所示：
步骤 #2 — 排序事件
接下来的步骤通过将事件按顺序（通常从左到右）来帮助识别任何可能缺失的事件。订单建立后，您可以向后转移以帮助识别其他事件。在我们的电商例子中，首先输入订单信息，然后输入正在检查的库存。在把它们放在一起时，我们发现我们为正在执行的输入检查留下了一个事件。
当同时发生多个事件时，您可以垂直堆叠它们，如下所示：
步骤 #3 — 识别用户和系统
在按顺序排列事件之后，下一步是通过提出 “是什么触发事件？” 等问题来建立围绕事件的更广泛的生态系统模型。这是一个系统还是用户？又或者是另一个事件？涉及哪些命令？
额外的业务上下文对于了解业务域的当前状态非常有价值。在我们的示例中，用户是触发订单信息输入事件的内容，他们通过网页（系统）进行操作。
步骤 #4 — 事件初步分组
此时，应对所有领域事件及其相关部分进行分类建模。
第一个分类称为聚合；这些是事件操作的名词或对象。领域驱动设计还有一个实体的概念，你可以把它看作是聚合的下一层。将聚合和实体作为相同的处理有助于简化事情，使人们更容易理解。在我们的示例中，库存、订单、报价都是分类示例。它们是事件正在操作的对象。
步骤 #5 — 相关事件归类到同一个边界中
现在，我们已经准备好了识别聚合的界限上下文。所有相关事件都将在一个限界上下文中。例如，与购物车相关的所有事件都会在购物车限界上下文中。这里要记住的一个重要的微服务概念是，如果它一起改变，它应该放在一起。我们希望尽可能消除跨界上下文的依赖关系，如果事件之间的语言发生变化，那么这表明您已经进入不同的限界上下文。
步骤 #6 — 最后汇总
现在我们已经完成了事件风暴所有的步骤！现在，您可以同时使用限界上下文和聚合来分解所需的微服务。通常，限界上下文中的聚合表示一个或多个微服务。
在我们的示例中，订单捕获限界上下文将包含与订单和库存相关的微服务。您会注意到订单也存在于购物车限界上下文和订单履行限界界上下文中。这没关系，这表明它们是不同的微服务，因为它们处于不同的限界上下文中。他们可能都在做与订单有关的事情，但他们做的事情是不同的。在一个单体应用中，这些将被捆绑在一起，导致耦合，但使用微服务体系结构，我们将它们进行解耦，满足高内聚和独立性。
现在，您有大量的信息可帮助您开始技术架构实现。我发现添加一个从事件创建业务能力（业务功能）的步骤很有帮助。通常，该功能通常是一般现代时态的事件。然后，这些功能可以映射到限界上下文，并在各种目标功能体系结构视图中聚合。这些不同的视图为架构师和软件工程师提供了构建其目标状态的蓝图。
结论
数字化产品是这个时代最主流的产品，而基于云服务的软件和服务交付则是如今和未来最广泛的产品开发迭代方式；技术服务于业务，拥抱技术的同时千万别忽略业务，本文从日常微服务拆分的痛点出发，很多疑问来自如何分解业务到不同的微服务，标准是什么？怎么保证服务高内聚？而业务架构是要优先于IT架构，不能为了偷懒或者不重视而直接进入开发环节；
最后，业务架构的领域驱动和事件风暴方法，需要不断的实践，我的经验，这些方法远没有新技术本身复杂。
参考资料和扩展阅读：
- 《Decomposing the Monolith with Event Storming》https://medium.com/capital-one-tech/event-storming-decomposing-the-monolith-to-kick-start-your-microservice-architecture-acb8695a6e61
- 《维基 - 企业架构》https://wiki.mbalib.com/wiki/%E4%BC%81%E4%B8%9A%E6%9E%B6%E6%9E%84
- 《维基 - 业务》https://zh.wikipedia.org/zh-hans/%E4%B8%9A%E5%8A%A1
- 2016年 AWS S3 新闻稿，https://press.aboutamazon.com/news-releases/news-release-details/amazon-web-services-launches-amazon-s3-simple-storage-service
申明
本站点所有文章，仅代表个人想法，不代表任何公司立场，所有数据都来自公开资料
转载请注明出处
诞生于 2019，遇见 2020。
感谢关注，欢迎动动手指标星和置顶；
这样就不会错过少但精彩的技术探讨、团队建设、案例分享！
每周至少一更，转发是对我的最大鼓励！
学习之路漫漫，走走停停，
偶有所感，随心所记，
言由心声，问心无愧！
从客户中来，到客户中去！
