业务架构之产品经理的职责

产品经理的职责

用户的原始需求往往是零散和碎片化的，产品经理的职责就是：告诉用户，系统长什么样子；告诉开发，他要实现什么功能。

产品经理定义了系统的外表。产品经理的职责：

1、收集用户的原始需求，

2、梳理成一个个业务流程，每个业务流程由多个业务步骤组成。一个业务步骤包含三部分的内容：输入、输出和业务功能。

3、需求梳理好后，产品经理会把每个步骤具体化为页面原型。在原型中，会以直观的方式给出各个步骤的输入或输出，以及用户的操作过程，最后再把这些页面串起来，形成一个业务流程。

业务流程例子：

按照业务域来划分系统模块，有多少业务领域，就有多个系统模块，流程中的业务节点按照业务域的不同，可以划分到不同的系统模块。

注意不是按照业务流程划分，有多少业务流程，就有多少个系统模块，这个对应关系比较直接，但实现起来很困难。而且这种模块划分的方式并没有降低总的业务复杂度。

业务划分的目标

1、业务的可扩展

业务架构设计要能支持打造一个柔性系统，通过提供良好的业务扩展性，允许业务不断调整和快速生长。

业务的主题是变化和创新，系统的主题是稳定和可靠。

2、业务的可复用

首先，模块的职责定位要非常清晰。对于模块来说，在定位范围内的职责要全部涵盖到，而不在这个范围的职责全部不要。

其次，模块的数据模型和接口设计要保证通用。架构师需要归纳业务场景，通过抽象提炼，形成通用化的设计，以此来满足多个类似场景的需求。

小提示：清晰的模块定位和通用化设计，是模块能够复用的内在要求。

最后，实现模块的高复用，还需要做好业务的层次划分。我们知道，越是底层的业务，它就相对更固定。

模块划分是需要考虑的重要问题：业务复用性。复用其实也是业务扩展性的基础。

复用的分类复用有多种形式，它可以分为技术复用和业务复用两大类。技术复用包括代码复用和技术组件复用；业务复用包括业务实体复用、业务流程复用和产品复用。从复用的程度来看，从高到低，我们可以依次划分为产品复用 > 业务流程复用 > 业务实体复用 > 组件复用 > 代码复用。

代码级复用和技术组件复用都属于工具层面，它们的好处是在很多地方都可以用，但和业务场景隔得有点远，不直接对应业务功能，因此复用的价值相对比较低。

业务实体复用针对细分的业务领域，比如订单、商品、用户等领域。它对各个业务领域的数据和业务规则进行封装，将它变成上层应用系统可以直接使用的业务组件。

业务流程的复用针对的是业务场景，它可以把多个业务实体串起来，完成一个端到端的任务。相比单个的业务实体复用，业务流程的复用程度更高，业务价值也更大。

最高层次的复用是对整个系统的复用，比如说一个 SaaS 系统（Software-as-a-Service），它在内部做了各种通用化设计，允许我们通过各种参数配置，得到我们想要的功能；或者说一个 PaaS（Platform-as-a-Service）平台，它会提供可编程的插件化支持，允许我们“嵌入”外部代码，实现想要的功能。

从技术复用到业务复用，越往上，复用程度越高，复用产生的价值也越大，但实现起来也越复杂，它能复用的场景就越有限。

但如果我们能进一步打造业务中间件，并在这个基础上，形成业务平台，这样，我们就能实现更高的业务级复用，可以更高效地支持系统的快速落地。

业务架构之业务模块构建

业务模块构建要求

每个模块都代表了某个业务概念，或者说业务领域。

模块内部由数据和业务逻辑组成，其中数据是核心，业务逻辑围绕着数据，对数据做进一步加工，方便外部使用。

对模块的要求：

1、定位明确，概念完整。数据上，模块需要覆盖对应业务领域的全部数据；功能上，模块要包含业务领域的全部功能。

2、自成体系，粒度适中。粒度划分得太小，导致系统的碎片化；体量过大的模块，我们称之为“肿瘤”，可维护性很差。

3、依赖关系明确。简化模块的依赖关系，我们就要同时简化依赖的方向和减少依赖的数量。避免松散的网状结构，尽量把网状结构转化为层次结构。

业务模块的构建步骤

构建步骤：

通过构建合理的模块体系，有效地控制系统复杂度，最小化业务变化引起的系统调整。

打造可扩展的模块体系：

1、模块拆分我们先对系统进行模块化拆分，拆分有两种方式：水平拆分和垂直拆分。

水平拆分是指从上到下把系统分为多层，按照系统处理的先后顺序，把业务拆分为几个步骤。垂直拆分指的是按照不同的业务线拆分。

一般做业务架构时，我们先考虑垂直拆分，从大方向上，把不同业务给区分清楚，然后再针对具体业务，按照业务处理流程进行水平拆分。

举例：

2、打造可扩展的模块体系：模块整合

通用化整合：通用化指的是通过抽象设计，让一个模块具备通用的能力，能够替代多个类似功能的模块。

平台化整合：平台化是把定位相同的模块组织在一起，以组团的方式对外提供服务。对于外部系统来说，我们可以把这些模块看成是一个整体，一起对业务场景提供全面的支撑。

业务架构之常见业务架构

服务端常见业务架构

1、单体架构

单体应用内部一般采用分层结构，从上到下，一般分为表示层、业务层、数据访问层、DB 层。表示层负责用户体验，业务层负责业务逻辑，数据访问层负责 DB 的数据存取。

2、分布式架构

分布式架构，简单来说就是系统由多个独立的应用组成，它们互相协作，成为一个整体。

3、传统SOA 架构

4、新的 SOA 架构

5、微服务架构

终端常见业务架构

分布式的系统架构App 前端直接对接多个后端应用提供的 HTTP 接口。

每个业务线的服务端进行拆分，让 App 接口和 PC 端接口各自在物理上独立，但它们共享核心的业务逻辑。

App 前端会通过移动网关来访问服务端接口。这里的网关主要就是负责处理通用的系统级功能，包括通信协议适配、安全、监控、日志等等；网关处理完之后，会通过接口路由模块，转发请求到内部的各个业务服务，比如搜索服务、详情页服务、购物车服务等等。

业务架构之基础服务的设计

基础服务边界划分的原则

1、服务的完整性原则

有些服务只是存储基础数据，然后提供简单的增删改查功能，这样一来服务只是一个简单的 DAO，变成了数据访问通道。这样的服务，它的价值就很有限，也容易被服务调用方质疑。划分服务边界时，要保证服务数据完整、功能全面，这样才能支撑一个完整的业务领域。

2、服务的一致性原则

服务内部的业务逻辑要尽量依赖内部数据，而不是接口输入的数据，否则会造成数据和业务规则的脱节（一个在外面，一个在里面），如果服务对外部的依赖性很强，就无法提供稳定的能力了。

3、正交原则

服务之间有数据的依赖关系，但没有接口的调用关系。

针对具体的业务场景，我们可以在上层的聚合服务里，通过聚合订单服务和商品服务来实现。

基础服务设计步骤

先弄清做什么：

服务边界划分，不主动调用其他服务、不负责和第三方系统的集成、只负责存储，不负责数据的进一步解释。

怎么做：

1、部分字段可配置：如流程状态等、也可配置主状态和子状态。基本状态称之为“主状态”，数量是比较有限的，状态之间的变化关系也是比较明确的，可以固定处理。子状态有哪些具体的取值，不同的项目是不一样的，可以开放给各个应用来定义。

2、拆分查询等级：查询接口可以根据返回字段数量的不同，提供三个不同粒度的查询接口来满足多样化的需求。第一个是粗粒度接口，只返回订单最基本的 7-8 个字段；第二个是中粒度接口，返回订单比较常用的十几个字段；第三个是细粒度接口，返回订单的详细信息。

3、设置不同等级的异步的消息通知。按照消息详细程度的不同，订单消息可以分为“胖消息”和“瘦消息”。顾名思义，胖消息包含了尽可能多的字段，但传输效率低；瘦消息只包含最基本的字段，传输效率高。如果外部系统需要更多的信息，它们可以通过进一步调用订单服务的接口来获取。