业务系统的需求分析设计

需求

假设我们需要实现一个积分系统，其包括积分的查询、消耗、增加以及消耗优先级。具体业务需要是参考业界的设计以及当下需要。这里不做阐述。

当业务需求确定好之后，如何将这个需求实现插入我们的系统中？

积分系统的合理系统设计

首先，我们需要明确的是，这个系统需要是成为单独的模块独立出去的，此处暂且不理会是使用哪种架构手段，因为这更多取决于当前项目阶段，而非业务问题。

那既然是要独立出去的模块，我们就需要遵循好系统设计中的设计模式，才能将其设计的高内聚、低耦合。

关于一个功能的设计，我们需要考虑的是界定功能范围、通信手段，有时甚至需要考虑到性能问题，譬如是否需要使用到多进程。

界定功能范围

在了解了业务的需求后，我们知道了积分系统的功能，但这并不意味着我们需要将这些功能一股脑的全部塞给积分系统来实现，如果系统设计是如此单一的话，那么设计模式也就没有用武之地了。

基于积分系统，我们有如下的三种设计。

使用中间层管理规则

这一种功能划分是把各种会涉及到积分规则都由营销系统来管理，而积分系统只负责对积分的增删查改这类操作。

比如，用户通过下订单赚取积分。订单系统通过异步发送消息或者同步调用接口的方式，告知营销系统订单交易成功。营销系统根据拿到的订单信息，查询订单对应的积分兑换规则（兑换比例、有效期等），计算得到订单可兑换的积分数量，然后调用积分系统的接口给用户增加积分。
积分规则由各子系统负责

这一种功能划分即为每个需要调用到积分系统的子系统各自设置对应的积分规则，然后自己调用积分系统实现增删查改功能即可。

用户下订单成功之后，订单系统根据商品对应的积分兑换比例，计算所能兑换的积分数量，然后直接调用积分系统给用户增加积分。
积分规则包含在积分系统内

这类方式中，积分系统不再只包含增删查改功能，同时还具备着各类积分规则。当用户下订单之后，只需将订单信息通知给积分系统，积分系统则会根据积分规则来判断需要做何种执行。

为了避免业务知识的耦合，让下层系统更加通用，一般来讲，我们不希望下层系统（也就是被调用的系统）包含太多上层系统（也就是调用系统）的业务信息，但是，可以接受上层系统包含下层系统的业务信息。在上述的例子中，订单系统为上层系统，积分系统为下层系统。所以订单系统可以包含积分的相关信息，但是积分系统最好不要包括订单的相关信息。所以这里面我们需要使用的是前两个方案，这两个方案的下层系统没有包含上层系统的信息，只是执行了积分的增删查改。

通信手段

上述我们对功能的划分中都有信息的流转，那么这些信息该使用何种手段进行传递呢？

比较常见的系统之间的交互方式有两种，一种是同步接口调用，另一种是利用消息中间件异步调用。第一种方式简单直接，第二种方式的解耦效果更好。

我们对通信手段的选择主要就从其功能角度和依赖关系来判断。

功能角度

用户下订单成功之后，订单系统推送一条消息到消息中间件，营销系统订阅订单成功消息，触发执行相应的积分兑换逻辑。这样订单系统就跟营销系统完全解耦，订单系统不需要知道任何跟积分相关的逻辑，而营销系统也不需要直接跟订单系统交互。

依赖关系

使用同步或者异步调用的另一个判断逻辑是：当前调用逻辑是否有依赖关系，比如下完单产生的积分立即被使用，那么推荐使用同步接口调用；如果生成的积分需要等待下次才能使用，推荐使用异步消息调用

同步接口的场景，业务执行的前提是依赖的业务正常执行。异步接口的场景，业务执行完毕后notify其他业务即可，即使这个notify出现问题，也不影响当前业务的正常执行。

业务模型的设计

在业务模型的开发中，我们常常会使用到分层模型，关于分层模型，我在Android 的架构演进 - 掘金 (juejin.cn)一文中有讲到，里面说到分层模型的优点是 结构清晰、利与管控，同时也方便人员分工。这里我再次将分层模型的优点列为以下的五点。

譬如MVP、MVVM等分层架构

分层能起到代码复用的作用：M层中的数据处理能力是可以被不断复用的。譬如其中被抽象为接口的网络访问部分，就是可以不断被复用的M层。
分层能起到隔离变化的作用：分层结构中，每层的稳定性不同，相互之间是隔离的。改变稳定性差的层次(高层)，对稳定性强的层次(底层)影响不大
分层能起到隔离关注点的作用：分层能让每层关注的功能更加的单一，符合单一职责原则
分层能提高代码的可测试性：分层模型便于单元测试，譬如我们可以直接对M层中的功能进行验证
分层能应对系统的复杂性：当系统变得复杂和庞大的时候，拆分层次总是能解决问题，使其维护性变得更好。拆分有垂直和水平两个方向。水平方向基于业务来做拆分，就是模块化；垂直方向基于流程来做拆分，就是这里说的分层

在这些设计中，我们使用到的一些设计思想如下