微服务如何对齐业务架构.docx

? ? ? ? ? ? ? ? 微服务如何对齐业务架构 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 作为开发人员和架构师，我们经常困惑于业务架构，又或者如何将业务映射到微服务实现，传统模式，业务专家 BA 进行业务相关的调研分析，将需求分析说明书交付给研发团队进行后续迭代开发，而在基于云基础设施的业务敏捷创新的今天，从业务到研发再到运维，协作的越好，整体效率和应对市场变化的能力就越高，从而接受市场反馈，不断迭代验证的过程就越顺利，无论正反馈还是负反馈，都是满足客户业务迭代的“良药”，从而极大增强了团队和企业的反脆弱性。另外一个常见的挑战是，对于一个已经在运行的单体应用，如何优化改造成微服务？通常，该应用已经存在很多年，有非常多的依赖关系，没有一个超级英雄，掌握所有细节。 无论哪种情况，“业务领域专家”重新梳理业务愿景和目标，再到业务流程再造，是系统演进和改造的关键环节。 - 1 - 什么是业务架构？ 通常业务架构不被开发人员重视，开发人员往往追求新技术，而技术是服务于业务，设计好的业务，需要做的业务领域的隔离和解耦，同时业务领域和技术架构也需要解耦。 “技术归技术，业务归业务”，这种泾渭分明的分工在数字化和云计算时代显得有点格格不入，就拿亚马逊 AWS 来说，为什么我们定义 AWS 是面向构建者、创业者和创造者的云？数字化产品是这个时代最主流的产品，而基于云服务的软件和服务交付则是如今和未来最广泛的产品开发迭代方式。 早在1987年，John Zachman 就提出?”企业架构“模型，该模型从不同的角色视角定义了“5W1H”，即 ”What（数据）“，”Where（网络）“，”Who（角色）“，”When（时间）“，”Why（动机）”和“How（功能）” 企业架构通常分为业务架构和IT架构，所谓业务架构，是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF 框架详细描述了如何定义“业务架构，应用架构，技术架构，数据架构”，是流行的企业 IT 战略规划的最佳实践指引。 在 TOGAF 中，定义了业务架构的部分交付物有，组织、驱动力、角色、业务目录、流程，事件，控制等、用例图、流程图等。 所谓”业务架构“本质上是解决业务复杂性问题，将”问题域“进行思考、抽象、分解和归纳过程成业务领域模型过程，这个过程中，我们需要，（1）所有业务方对于业务目前现状（AS-IS）和未来愿景（TO-BE）有个共同的理解和愿景（2）业务交互过程的理解，一项业务往往涉及很多业务过程，比如购物车业务，涉及添加商品，删除商品，计算商品金额，清空购物车，调整商品数量等场景。 - 2?- 如何落地业务架构？ 认识到业务架构的重要性尤其是对于开发人员而言同样重要是技术人员主动参与业务架构的第一步；那在具体项目中如何实践落地业务架构呢？ 首先，开发人员要摒弃技术“细节”惯性思维，尤其不要把业务简单对照到数据库的增删改查，从宏观再到微观，比如最近涨了火热的股市，你有研究过股市业务吗？两融，北向资金，打新，竞价，印花税，注册制，限价买入，逆回购，交易撮合等等；这之后才能真正做好程序化交易，或者开发股票交易软件等数字化产品。 其次，业务架构的方法很多，比如领域建模、事件风暴、用例、四色建模等等，没有一劳永逸的“银弹”，掌握每个方法的特点，找到适合自身业务和团队的方法。 再次，纸上得来终觉浅，一定要实践，业务架构相关的理论很重要，但更重要的是实践，讲再多也不如在一个项目中实践学到的多，别犹豫，先做再说。 通常，业务架构首先需要创建业务能力模型，以映射业务能力并将其与特定层次的业务实体对齐；但分类本身并不提供更广泛的限界上下文，也不能深入了解如何将功能分解为微服务，这是事件风暴可以帮助的地方。 事件风暴由 Alberto Brandolini 首创，是一种互动方式来进行域驱动设计 (DDD)的方法，主要协作对象是所涉及的业务和技术部门的领域专家；后续篇章，我将引用一个深入迭代的事件风暴示例，展示如何将其应用于您的架构工作。 - 3?- 什么是事件风暴？ 什么是事件风暴？我们先来澄清一些关于事件风暴的常见误解。 - 3.1?- 事件风暴等同于领域驱动？ 领域驱动设计是以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型，由领域模型驱动软件设计，用代码来实现该领域模型； 虽然事件风暴继承了许多领域驱动的概念（包括限界上下文和聚合），但正式的领域驱动设计可能会很复杂，需要大量的培训。而事件风暴侧重于交互式协作白板练习，让所有领域专家都参与进来。它更简单，不需要像正式的领域驱动设计那样广