在 上一篇 文章中主要讲了业务架构的基础部分，整体的 业务架构 还有一些其它点要考虑，如业务之间的彼此隔离、业务与技术 (平台) 的隔离、业务能力地图的可视化、业务 mock 能力、业务监控等，本篇文章主要讲述这些内容。

一、业务彼此隔离

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

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

  • 业务自身需求：这个很好理解，不同的业务有自己的特点。
  • 业务之间的互不影响：隔离的目的就是为了互不影响，将变化的东西缩小到业务线内，不可能改动一个业务线的需求，结果把其它业务线影响了。
  • 业务的 可扩展性：平台型的业务有一个最大的特点是要较好地支持可扩展性，往大的方面讲，新接入一条业务线的改动有多大、往小的方面讲，对于某个业务线内的需求改动又是多大，比较好的状态就是具备 可配置，稍微配置一下，一个新业务线就接入，这是我们最想看到的结果。

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

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

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

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

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

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

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

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

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

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

三、业务能力地图

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

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

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

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

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

四、业务 mock 能力

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