要设计加油网络的业务架构，首先要了解加油网络的业务模式，这个可参考之前的文章<加油网络，想清楚这几点才是关键>。软件架构设计的核心是建立业务模型，模型分为核心模型，辅助模型，通用模型这几种。要想设计复用性高，扩展性强的系统，我们需要从下面这几方面来考虑。
软件系统=模型+关系。
软件系统的设计从工程性角度看，可以拆分为模型、关系两部分。
模型由数据和业务逻辑组成，是以数据为核心，业务逻辑围绕数据做进一步加工，方便对外使用。加油网络设计上，“油站”是核心模型，如果设计SaaS的话，进销存是核心模型。油站模型设计时，要在以下方面注意：1、数据的全面性，要包含油站业务域的所有数据，这包括油站基础数据，价格数据，设备数据，发票数据，通道数据。2、功能的全面性，包含油站增删改，业务规则校验，状态、生命周期管理等。
模型设计的关键是边界清晰，粒度适中。加油网络的模型拆分如下，核心模型：油站。辅助模型：油站价格，油站设备，油站发票，通道数据。通用模型：渠道商户，用户，订单，支付，营销。特别要强调的是，因平台运营的重点是tob方向， 所以渠道商户模型可以说是，系统的第二个核心模型。
关系是指模型之间的协作方式，实质体现的是模型的组织结构。模型间依赖关系的设计重点是，“简化依赖的方向和减少依赖的数量”。
依赖方向设计上，要采用单向依赖的分层结构，这样的设计是结构化的也能和业务流程对齐。本质是逐层隔离变化点，把需求的影响降低到最小。
依赖数量设计上，可采用聚合模式，相同定位的模型聚合在同一个层里面，这样从整体看就是层与层之前的依赖了，这样，从人理解业务的角度，依赖的数量大幅度地减少了。
下面是一张 MVC 分层结构图，可以看到，系统总体上是非常清晰的层次结构。
清楚了系统的组成后，我们再看下业务流程和模型的关系。
业务流程不能用于模型拆分
业务流程产生于用户原始需求的收集，每个业务流程由业务步骤组成，每个业务步骤分为输入、业务操作、输出三部分。
比如，一个典型的一键加油流程，它包含油站选择、油品选择、下单、支付等步骤。其中，下单步骤的输入，就是订单的各种信息，下单的业务操作，就是整合这些信息，创建一个具体的订单，而下单的输出结果，就是新创建的订单。
是不是可以按照业务流程来划分系统模型？答案是不可以。
每个业务都有其本身的专业性，比如加油业务、订单业务、支付业务，它们的数据模型和业务逻辑都相当复杂，都是相对独立的业务领域。如果我们是按照业务流程来划分系统模型，结果是把不同业务混在了一个模型里了，所以，这种模型划分的方式并没有降低总的业务复杂度。
我们可以按照业务域来拆分系统，首先需要先把所有的业务流程拆散，这样得到了一堆业务节点，然后，把业务节点进行归类，相关的业务节点放在同一个系统模型里。判断节点是否相关，主要看它们是否属于同一个业务领域，比如一个油站查询的节点，和油站创建的节点，它们都属于油站域，那么这些节点都可以归属到同一个油站模型里。
下图就清楚地展示了系统模型按业务流程拆分，和按业务域拆分的不同。
基于业务领域，拆分了系统模型后，就可以按照这样的方式还原整个业务流程，比如上面的一键加油流程，就可以这样还原它：
一键加油流程 = 油站模型. 油站列表 + 油站模块. 油站信息 + 订单模块. 创建订单 + 支付模块. 支付
加油网络系统架构说明
我们既然知道了系统=模型+关系，也知道了不能按照业务流程来拆分系统。下面我们就可以来设计加油网络的业务架构了。业务架构的目标是系统的高复用性和高可扩展性。
从上面的架构图可以看出，在业务架构上，我们首先做了一键加油、加油券、车主平台服务业务线等垂直方向的业务拆分，了解了每条业务线的流程后，我们再次按照业务域进行了水平拆分。这样我们就得到了一个二维的模型矩阵，每个模型既属于某个业务线，也属于业务流程的某个环节。这样一来，每个模型的职责都很清晰，当业务变化了，我们可以清楚地知道，这个变化涉及哪些模型，然后，对这些模型进行相应的调整就可以。
高扩展性设计上，我们把业务平台和业务线剥离开，让业务平台封装基础业务的功能，这样，它就变得相当地稳定，各个业务线包含自己的个性化需求，业务线只依赖业务平台，业务线彼此之间互相独立，可以自由变化。这样的业务架构设计，就同时保证了系统的相对稳定和业务的高扩展性。
比如，加油网络会在B端业务上对接多条业务线，因而对系统扩展性要求比较高，要能快速对接新业务并且还能保证系统的稳定，故而，我们架构时要单独做B端业务模型的设计，提供基础的商户、价格、策略、Open API等服务给上层，这样把业务需求内敛到B端业务模型内，做高内聚的模型。
在高复用性的实现上，我们在拆分完系统模型后，把业务线需要的相同需求提取出来，放到基础平台。比如，油站信息，订单信息，支付信息等。同时，我们可以尝试把一个业务域按照层次拆分得更细，比如，把价格模块拆分为多个上层价格模块和一个基础价格模块，这样，基础价格模块对于所有类型的价格，都能够提供复用。
基础平台的内部服务之间是正交关系，它们处于调用链的底层，服务之间不会有任何的调用关系。比如说订单服务和油站服务，它们代表不同维度的基础业务域，彼此之间不会有调用关系。
比如，订单明细里包含油站 ID 信息，但订单服务内部不会调用油站服务来获取油站详情。如果页面需要展示油站的详情，针对这个具体的业务场景，我们可以在上层的聚合服务里，通过聚合订单服务和油站服务来实现。
总结，加油网络业务架构的设计，首先是，按照业务域先纵向再横向拆分系统模型，然后，追求的是高扩展性和高复用性的设计目标。
