架构思维第二篇

Posted 2021-06-22 hanruikai

业务架构

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

 

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

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

 

 

 

业务架构方法

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

 

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

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

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

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

优惠券业务举例

 

系统思考

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

 

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

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

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

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

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

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

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

 

业务流程

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

分解和抽象

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

 

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

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

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

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

 

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

 

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

业务架构

 

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

 

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

 

业务与业务隔离

 

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

 

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

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

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

 

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

 

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

 

业务与平台的隔离

 

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

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

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

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

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

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

 

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

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

 

业务mock能力

 

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

 

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

 

mock 主要方便问题重现和定位。

 

业务监控

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

没有业务监控的系统对业务的运行状况一无所知

 

原文地址：

https://www.infoq.cn/article/G*DTr9RmIyh0hR59ZTug