系统架构之业务架构实战

引言

业务架构一般不被开发重视，开发人员喜欢追求新技术，而技术是服务于业务的，现在没有一项技术是自娱自乐的，一定要支撑业务，否则没有场景。设计好业务架构要考虑的方面比较多，要做到业务彼此隔离、业务与技术 (平台) 隔离，从业务架构中能看得出整体业务的流程运转、业务产品的能力、业务领域对象…

一、什么是业务架构

系统架构的方法：系统性思考、分解、抽象、模式，这是总的纲要，针对不同类型的业务架构，要结合本身的特性再加以细化。

业务架构是系统架构的一种，那什么是业务架构呢？业务在百科中的定义是” 涉及一个以上组织，按某一共同的目标、通过信息交换实现的一系列过程，其中每个过程都有明确的目的，并延续一段时间 “。从这句话可以看到几个关键词：组织、目标、过程，下面仔细分析这几个关键词的含义。

• 组织：业务涉及到的人或者组织，这个比较好理解，一项业务应该由多个人来完成，如销售、财务、产品、研发、售后等。

• 目标：这是做这项业务的目的和价值，换言之，为什么做这项业务，做好这项业务要达到的目标是什么。

• 过程：过程就是业务过程，一项业务由多个过程组成，如优惠券业务，它的过程是建券、发券、用券、退券。

上面这样的描述可能比较空洞，与我们平时接触的不匹配，再继续提炼出重要信息。

• 利益相关者：这个是从 ” 组织 ” 和 ” 目标 ” 中推导出来的，业务的受益方是谁，为什么要做这个业务，肯定有受益的群体，否则没有市场。如优惠券的利益相关者有用户、商户、公司，因为用户下单可以使用优惠券、商户可以吸引更多的客户来消费、公司的GMV就上升了。

• 业务流程: 这个是从过程推导出来的，并且这个业务流程是固定的 (至少一段时间内)。这里的业务流程是大的流程，每个流程都会再往下分解成子流程，如优惠券中的发券，它会有一系列子流程，如发放规则检验、风控安全等。

综上，到这里，也可以用一个公式来定义业务架构，业务架构 = 业务目标 + 业务流程 + 业务要素，这和系统架构的定义非常相似，只不过是实例化了而已。从业务架构的公式中，最重要的是识别出业务流程和业务流程中包含的业务要素，换个角度来看就是业务要素与业务要素之间的关系，这些关系组成了整个业务。

二、业务架构的特性

已经知道了业务架构是什么，接下来就讨论业务架构的特性，通过特性基本上就知道业务架构的大体框架。笔者通过 x、y 数轴加以说明，因为业务要体现出业务流程的流动性和业务的层次性，下面就说明这两个特性：

• 业务的流动性：其实这是业务生命周期的体现，从产生、拥用、使用可以看出业务的流动，这是横向的。

• 业务的层次性：笔者一般习惯用场景层、产品功能层、领域模型层、依赖层来画业务架构图，这是纵向的。场景层依赖下面的产品功能层，多个场景很有可能对应一个产品功能，产品的功能又是由领域模型来支撑的。

三、业务架构的方法

业务架构的方法还是从系统性思考、分解、抽象、模式这四点具体说明。

• 系统性思考：站在业务的角度，分析业务与业务之间的关联性，如优惠券业务，它就涉及到人群选择、风控安全、活动、会场、优惠、交易、凭证等，思考系统之间的交互和依赖关系，以及依赖系统要提供的哪些能力。

• 分解：系统性思考让我们的目光放得更广，整体上考虑整个业务的运转，此时还没有想业务的具体流程，只是知道有，并不深入考虑如何做。分解就不一样，它聚焦的是业务本身是如何运转的，一般业务由几个主要的流程组成的，每个流程又能往下继续分解出细的流程，分解的目的是为了找出业务的要素，此时的元素都是孤零零的。

• 抽象：分解不是我们的目的，通过分解找出的业务要素，此时要经过一定的抽象才能形成我们的领域对象，因为分解找到的业务要素很多是可以合并归类的，这样就大在减少了业务要素，也降低了理解的复杂度。

• 模式：通过业务架构的特性，按照场景层、产品功能层、领域模型层、依赖层这四层画出业务架构图。

所以方法还是上一篇所提到的方法，只不过套到具体类型的架构中，具体化分析。有的时候在想，并不是业务架构难搞，只是我们并没有像追求技术那样投入时间研究业务架构，可以不断运用上面的方法，结合自己的理解和扩展，多去实践。

四、通过实例画出业务架构图

下面通过一个电商场景的优惠券业务案例来说明业务架构图是如何画出来的，使用的方法还是上面提到的，通过具体的例子再加以巩固。优惠券对于我们来讲并不陌生，每年的双 11 都有很多优惠券，有满减券、折扣券，优惠券是营销中最常使用的营销抓手。

4.1 优惠券业务愿景和目标

优惠券的业务愿景是让用户可以享受到更多优惠，目标是通过优惠券吸引更多用户加入，从而提升 GMV。

从这里可以看出，愿景一定是为他人着想，绝不是为了公司自己赚钱，而是创造价值的同时实现双赢，双赢才是最终目标。

4.2 系统性思考优惠券业务

如何进行系统性的思考，笔者建议可以使用反推法，假设已经有了这项业务，它应该是如何运转的、涉及到哪些人，实际上这个过程就是推演的过程，基本上能把整个交互都考虑清楚，业务实现起来基本上没问题。

• 用户：用户有优惠券，下单会使用优惠券，涉及到交易和优惠。

• 系统：涉及到建券、发券、核销券、退券

• 建券与我们优惠券系统关联最大，也即是我们要做的事。

• 发券，发给谁呢，肯定不是遍地撒网，现在基本上是精准营销了，要知道哪些用户是活跃用户，所以涉及到算法推荐；除了发给谁是我们关心的，营销还有一个比较核心的点，就是营销模式，你怎么能吸引用户，这就涉及到会场、活动，这些玩法是非常关键的。

• 核销券：优惠券券在什么条件下可用 (满 100 元减 10 块)？订单价格如何计算出来的？

• 退券：退款了，券要不要退回？

所以，经过上面的分析，初步涉及到的业务方就已经出来，此时还只是一个粗略的关系，这个过程可能需要几轮不断的讨论最后才成型。

4.3 优惠券业务流程

业务流程是客观存在的，而且任何一个业务在一定的时候内应该有一条稳定的业务流程，这个业务流程是符合人的认识的，具有严谨的逻辑性。怎么理解呢？一个业务要运转起来，不可能是一团糟，一定具备流程，而且是人能接收的，否则你设计一个反人类的业务产品出来，注定是失败的。拿优惠券来讲，根据它的生命周期，很容易想到它的主业务流程：建券、发券、用券、退券。

4.4 分解和抽象

上面是一个大的流程，还要对各个流程再进一步细分，分解成更小的子流程，每个子流程中包含一系列的步骤，其实这个步骤就是不断深入地过程，同时对业务的理解也不断加深，多问几个为什么就深入了。

• 建券：这个券包含了哪些内容？

• 发券：给谁发？发券的条件是什么？

• 用券：什么条件下能使用优惠券？用券涉及到哪些过程？

• 退券：什么场景下会退券？

随着深入的过程，整个业务的细节也浮现出来了，现在就是要抓业务要素，这个要素可以通过每个阶段的产物来看。建券的产物是券批次，发券的产物是券实例，用券的产物是用券明细，退券的产物是退券明细。

接下来就是抽象的过程，这个抽象的过程就是对已找出的产物进行抽象。券批次包含：券类型和券门槛限制两个重要的信息，用券明细和退券明细统一抽象成券明细，优惠券又与活动强相关，所以也把券活动放进去。

4.5 优惠券业务层次结构

接下来就是画整体的业务架构图了，按照场景层、产品功能层、领域模型层、依赖层来画，画业务架构图要体现两点出来：业务流向和产品功能。通过下面的图可以直观地感知业务流向是什么 (即是蓝色区域，建券、发券、用券、退券)，通过分层可以清晰地看到可以支持的场景有哪些，场景依赖的产品功能有哪些，业务的领域模型是什么，依赖的业务又有哪些，真正好的图能做到一图胜千言的效果。

笔者喜欢的画法是 ” 一主两翼 “，主体的部分就是上面讲的分层，两翼是运营平台和数据平台，这样很直观、简洁。

五、小结

本篇主要讲业务架构的定义、特性以及业务架构的方法，最关键的是寻出业务的要素和要素之间的关联关系，最后通过一个实例来讲解业务架构的画法，是业务架构的基础，通过这个业务架构图基本上知道业务的流转和业务的产品功能。

一、业务彼此隔离

在较小的公司可能要体现这个没有对应的业务场景，但在大公司中，如果业务是平台型的，承接的业务方较多，业务方之间的需求还不一样时，就体现出了业务与业务之间的隔离。比如，优惠券业务是平台型业务，有多个业务线的业务方接入，它们的诉求也不尽相同：有的要实现业务线内不同用户角色的打通 (乘客、司机等)、业务线之间风控策略也不一样、优惠券发放规则也不一样…

业务与业务的隔离需要有一个标识来唯一标志，阿里有的团队叫 bizId，在我们团队是通过 productId(业务线 Id) 来区分。标识说起来简单，但它只是第一步，隔离的表象就是通过业务线来区分。思考一个问题为什么要实现业务之间的彼此隔离？

• 业务自身需求：这个很好理解，不同的业务有自己的特点。

• 业务之间的互不影响：隔离的目的就是为了互不影响，将变化的东西缩小到业务线内，不可能改动一个业务线的需求，结果把其它业务线影响了。

• 业务的可扩展性：平台型的业务有一个最大的特点是要较好地支持可扩展性，往大的方面讲，新接入一条业务线的改动有多大、往小的方面讲，对于某个业务线内的需求改动又是多大，比较好的状态就是具备可配置，稍微配置一下，一个新业务线就接入，这是我们最想看到的结果。

通过 productId(业务线 Id) 这个唯一的业务身份串起整体业务，在业务处理过程中，可以知道这个业务线需要的具体业务策略和处理规则。

结论一：业务与业务的隔离体现了业务之间的变化和独立性，所以就产生了业务与技术 (平台) 的隔离。

二、业务与技术 (平台) 的隔离

业务与技术 (平台) 的隔离体现了变与不变的关系，虽然这句话被很多人讲过，但不同的系统实现的策略不一样。平台型业务一般要解决 80% 以上的共性问题，20% 左右通过开放来实现。

业务与技术 (平台) 的隔离不像业务与业务之间的隔离那样，两个业务之间没有交集，业务与技术 (平台) 之间是有交集的，这让人听起来有些蒙，下面细细分析。

• 不同业务线之间有一条共性的业务流程：虽然不同的业务线产品之间有各自不同的点，但它们之间有一个明显共性的业务流程，这个业务流程是业务的生命周期，就好比类与对象之间的关系，本质是同一类事物，不同的对象好比不同的业务线产品，具体的实现上有些差异。在优惠券中，核心的业务流程就四个：建券、发券、用券、退券，不管什么业务线接入，它都遵守这条固定流程。

• 业务变化的是子流程中的内容：不同业务线产品的不同之处体现在哪里？体现在业务细节上，这个是变化的，如业务的准入条件不一样、业务规则不一样、有的子流程中某一个处理步骤不需要…，这些是变化的部分，需要把变化的部分抽象出来并封装变化。所以，不变的是业务大流程，变化的是业务实现细节。

• 业务与技术 (平台) 的隔离理解的二重性：有些人理解业务与技术 (平台) 的隔离就是业务的实现不依赖于技术，比如数据要怎样存储？服务治理用什么框架？…这些说的是对的，它本身没有错。而我理解是有两重含义：一就是如上面所说的，业务的实现不依赖于具体技术，偏技术选型，这是常识；二是领域层的可扩展性，前 2 项已经说了业务的共性和变化，这个就是体现出应对变化的策略，尽管不同的系统有不同的具体实现，但总的原则是平台要能识别出这些变化，并能应对这些变化。

业务与技术 (平台) 的隔离体现在共性和变化的隔离，把变化的部分告知平台、实现开放出来，所以说它们是有一定交集，这个交集就是应对变化的部分。它涉及到技术方面，所以在技术架构中会单独拿一篇来讲。

结论二：业务与技术 (平台) 的隔离主要体现在处理业务的变与不变。

三、业务能力地图

我们有一个体会是开发和产品有时在谈一个需求时，开发用开发的语言、产品用产品的语言，两个很难统一，虽然通过领域建模可以统一认识，但是随着时间的推进，人员结构也在不断变化，如何快速熟悉业务、统一业务认识是一个问题。

发现通过业务能力地图来表示业务流程，可以减少沟通、统一认识、可视化表示业务产品功能所经过的关键业务路径，这样一个新人进来通过这个业务能力地图就可以知道业务的主流程是什么，产品功能涉及到哪些业务子流程，针对一个需求，开发不需要看代码哪里要修改，很直观地在业务能力地图可以知道本次需求涉及到的改动点，从而提升整体效率。

在做业务能力地图之前是有条件的，否则只是一家之言，有什么意思呢？就是业务已经进行了领域建模，业务产品和开发达成了统一的认识，业务的领域对象有哪些、业务的主流程、子流程有哪些、业务的准入条件、规则判断等，只有这些大家已经统一认识了之后，再通过技术手段把这些信息可视化表示出来就行，否则只会站在开发的角度来理解要表示哪些流程步骤。换言之，业务能力地图中所展示出的节点信息都是开发、产品统一的语言。

业务能力地图是领域模型的进一步扩展和延伸，领域模型偏静态的表达领域对象和领域对象之间的关联关系；而业务能力地图是动态的表达业务执行流程是什么。领域模型是基础，业务能力地图是进一步的扩展，一个表达有什么，一个表达怎么做，一动一静，可以更好的理解业务和业务流程所涉及到的核心步骤。

结论三：业务能力地图是在领域模型的基础之上进一步扩展，可视化地表达业务流程。

四、业务 mock 能力

业务 mock 能力是指 mock 用户数据方便排查问题，排查问题的第一步是重现问题，尤其是在端上，可能在某些条件下展示有问题，用测试数据又没有重现这个问题，如何来做呢？可以通过 mock 用户的信息来展示数据，说白了就一句话偷天换月，在最底层的查询时，把用户信息置换掉。举个例子，用户在下单时发现有些优惠券没有展示在列表页中 (实际上是有些优惠券不满足订单条件，如满减券、限门店使用等)，用户向客服反映，客服再向技术支持人员反馈，技术支持人员再往具体的开发反馈，这个链路就很长了。如果客服同学使用这项 mock 能力，完全可以通过 mock 用户数据来当前的数据是怎么展示的，再看用户所有优惠券，对比优惠券的限制规则就能知道哪些优惠券不能使用，这样就可以快速响应用户问题。

使用这个 mock 能力时，有一点需要考虑的就是数据安全，并不是所有的行为都可以 mock，一般来讲只有读场景下才能 mock；还有一点需要注意的是全链路 mock 范围，只有在指定的接口上才能 mock，不能直接从导购链路一路往下 mock，只会在最底层的业务接口上进行 mock，否则全链路数据都被置换了。

结论四：mock 主要方便问题重现和定位。

五、业务监控

业务监控也是非常重要的一个环节，不同的公司用的方法也不尽相同，也要看业务规模和公司的实际情况，不可能要求所有的公司都使用大数据来分析。根据自己的经历谈谈这块。

小公司直接统计业务数据表，比如之前做过金融，根据还款数据拆分成还款计划，还款计划再生成对应的还款订单，这里面的涉及到的业务数据就比较多，但能够很好地进行监控，当时根据业务数据状态、数量来判断业务是否已经处理完了，通过核对数据看今天的业务执行是不是正确的。这虽然很简单，通过写 SQL + 定时执行 shell 脚本就可以搞定，在业务的初创期它最简单，关键是提炼出监控的指标和维度。

在大公司，通过日志采集、清洗、实时统计，可以看出当前业务的处理情况，有同比、环节的数据，如当前下单率是多少，通过监控这个指标可以看出业务是否正常，如果下单率明显下跌比较厉害，大概率是哪个链路上出了问题。

通过业务监控大盘分别从不同的维度来监控业务运行状况，从而可以分析判断出当前业务是否受影响，帮助开发人员提前发现问题，这一块也涉及到稳定性方面，大公司是非常重视这一块的，阿里双 11 会专门成立稳定性小组，稳定压倒一切。

结论五：没有业务监控的系统对业务的运行状况一无所知。

六、小结

本篇文章是在上一篇文章的基础之上，对业务架构进一步补充，在平台型的业务中，着重注意业务与业务的隔离、业务与平台的隔离，实现最少的投入实现最大的业务价值。后面提到的业务能力地图、业务 mock 能力和业务监控是从工具层面上统一人员认识、提升沟通效率、快速发现、复现问题。接下来的系列就是技术架构了，从技术的角度解决常见的问题，如高并发、高可用、稳定性、高可扩展等。