上篇所讲的高聚合低耦合的宗旨，就是要用在产品设计上。此处所讲的产品设计，不只是界面设计，还包括产品架构、系统架构、功能模块、实体结构、角色、逻辑等等。

本篇文章分为整体设计和局部设计两个部分。整体设计是指从零到一开发或者重构一款产品的全部流程，一共涉及业务层、系统层、逻辑层和交互层等四个层面。局部设计是指产品正常迭代或者设计产品某小块下的流程和核心，局部设计的流程是整体设计流程的子集，所以主讲局部设计的核心。

大家在看的时候，时刻要想着“高内聚低耦合塑造产品认知”的宗旨。

整体设计

产品的整体设计包括业务层、系统层、逻辑层和交互层等四个层面。基于需求提出业务方案，基于可行可落地的业务方案进行设计。

在实际过程中，并不会严格按照顺序一层层下来，因为方法是层级的，而灵感则是跳跃的。我一般是先从业务方案中抽象出实体、角色和逻辑，

整体设计

业务层：业务方案

业务层是指业务方案。业务方案就是业务层面的方案，要求业务方案是可行可落地的。新产品/新模块的业务方案一般由产品经理、领导或者业务方提出，代表着在产品经理、领导或者业务方的思考中是如何解决这个问题的。

只有可行可落地的业务方案才有意义，因为产品经理就是要把可行可落地的业务方案搬到线上，做成标准化的解决一类问题。如果业务方案的不可行，那么后续的产品设计也就无从谈起了。

如果业务方案已经落地且可行，例如在运营层面已经按照某规则人工实行了一段时间，效果不错。产品经理就需要把这个方案搬到线上，要基于业务方案设计功能，做成标准化的功能解决一类的问题，还要结合整体和未来的发展。

如果没有可行可落地的业务方案，产品经理不仅需要和各方沟通出一个或者多个解决方案，还需要通过落地执行或者设计MVP等方法去测试方案的预计效果和可行性。有多个就对比选一个最好的，这里的最好可以是效果或者性价比等，具体请视情况判断。

当公司发展到一定阶段，业务和系统必定有一个是纵向有一个是横向，多个业务纵向铺开后，需要横向的系统打通，主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通。例如滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构，滴滴启动了中台战略整合业务系统。

以下《从滴滴出行业务中台实践聊聊如何构建大中台架构》

构建业务中台的四个原因

2015 年末，滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。随之，滴滴启动了中台战略整合业务系统。

决定构建业务中台主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通。

专业深度。由于是多业务垂直化的架构，会有多个团队开发同样的架构，这就需要很多的工程师。

每个团队都是用最快速的方式构建流程，所以技术很难做深。这样一来，导致客户端的流畅度不高，后端不稳定，影响可扩展性。

人力资源。从原则上来说把每个团队加到足够的人，每个架构都能有很好的发展。但工程师的薪资都非常高，招聘大量工程师来做同样的架构，研发成本高昂。还有些时候，即使你愿意花钱，也招聘不到合适的人。

用户体验。流畅度、稳定性、扩展性、界面、交易流程等都是影响用户体验的重要因素。

在当时的组织结构和研发情况下，会出现业务的应用场景不同，交易流程却相同的问题，这样很影响用户的体验。

全局打通。所有业务本质都是出行，出行本质具有协同效应。但在各自独立发展情况下，业务间完全没有协同性，在构建中台过程中，我们可以逐步把协同性建立起来。

构建出行业务中台的挑战

构建出行业务中台并不是只有好处，也一定会带来很多问题，最大的问题是软件复杂度。

从业务角度来说，把所有业务合并到一个体系下，本身就是很难的事，再加上滴滴出行是实时性 O2O 业务，场景差异很大，而且作为互联网公司，不仅有很多需求不明确，还会不断持续变化。

这种情况下，想要用一套相对稳定、相对固定的架构去支持所有业务，十分困难。

从组织角度来说，滴滴出行有多个事业部，业务涉及 400 多个城市，组织和个人的变化更快。

针对软件复杂度的挑战，中台制定了最基本的实现目标：在业务多元化发展的组织中，去构建一套工程架构，构建一套组织结构及对应的管理机制，以保证业务可持续的又快又好的发展。

滴滴业务中台的架构实践

在谈具体对策与实践之前，先来看看整个业务中台的架构设计，如下图：

整个的架构设计分几个边界的上下文，好处在于把相关性不强的逻辑拆开，同时在一个相关性下面，通过分层对业务进行更好的建模。

调度层作为入口去牵引多个业务线，业务流程层为调度层做服务，状态智能层用来支持上面的两层。

在对业务和产品进行更好建模的基础上，进行了“五化”：服务化、异步化、配置化、插件化、数据化。

服务化

服务化很常见，以下单为例，如下图：

下单流程能够调用很多服务，在多个层次，以接口层次结果进行拆解。

这里需要提醒的是服务化要注意如下三点：

• 服务之间的协议和规范要建立好。

• 注意控制力度，力度太小、太大都会有问题。

• 随着时间的发展，服务化本身要不断的演进。

异步化

对每个事件的非核心或不需要实时反馈给客户端的逻辑进行拆解，核心的主流程会变简洁。对非核心的逻辑在事件上做订阅之后，进行二级处理。

以结束订单为例，如下图：

结束订单的时候有很多逻辑要做，但是都是通过 MysqlBinlog 处理或 MQ 处理。

配置化

服务化和异步化能解决很多迭代效率的问题，但由于系统、业务的复杂性，各个业务都有些差异，体现在不同的产品线、城市、区域、时间等等。

配置化的核心是对这些进行建模，把每个对象模型化，抽象成 ID，在不同的服务化里把这些可配置的能力进行抽象。

具体抽象过程，如下图：

第一级抽象采用的是类 iptables 的规则引擎判定产品分类，第二级的规则引擎由模块自定义。

所有配置化都是用的自生成平台，要配置什么，自定义配置即可，这个过程是动态进行的。

当前业务中台已经可以支持上千个配置点，比如不同层次的计价规则不一样、不同产品线的车样子不同、不同的场景，如拼车和接送机，管控规则也不一样等等。

插件化

配置化解决的是业务线差异问题，但如遇到逻辑差异较大的情况，就要做插件，统称为 FPI。

在 FPI 的能力上，不同的团队可以开发很多插件，在特定的配置点下，对它的逻辑进行加载。

真正业务流程到这儿，可以调起它对应的插件做出来。对于一些没有差异化需求的业务，可以用开发的 default 逻辑，这是更极端的灵活性的体现。

有灵活性的体现后，团队还可以做一些组织上的调整，原来每个服务或者平台是一个垂直化的架构，有些团队是横向，是 FT，有些 FT 是接送机 FT，专门做接送机的事情。

通过插件的形式在每个系统加载它的插件，它就可以跟着业务思考、跟着产品思考这个业务该怎么走、这个产品怎么演化。

相对的逻辑是更加专注的，这也带来很好的组织结构对中台的适应性。

数据化

在大数据时代，数据是不得不考虑的问题，所以在业务中台，要实现全局打通，本质是要把数据打通。

所以我们制定了离线分析与在线决策的方案，如下图：

第一个是离线做分析，可以做数据血缘、模型训练，同时可以把它放到在线决策层面，构建很好的智能客户引擎和交易引擎，这个可以干预，因为干预可以让升舱或者多业务线的清单成为可能。

因为有这样的决策，使在线服务的管控和判断做得更加智能。

数据化方面，需要注意以下三方面：

• 让数据更加规范和标准化。

• 构建完整的数据流，从在线到离线，从日志到模型的在线使用。

• 引入机器学习的算法、人工智能的算法去构建在线数据智能的决策。

这是业务中台的五个对策，主要解决传统的系统架构问题，怎么做到高耦合和内聚，怎么提高迭代。

配置化和插件化解决灵活性问题，把灵活性开放给不同团队。数据化实际上是中台赋能业务，有中台的赋能才能变得更好。

经验总结

业务中台从无到有，到被应用的实践过程中，积累了很多实战经验。主要分享以下几点：

第一点：成功实现最大的业务孵化中台是滴滴出行构建业务中台最大的经验。

因为最大的业务最复杂，把最复杂的业务搞定，用最复杂的业务落地别的业务会容易。也就是从快车开始做，逐步整合专车、出租车、代驾等。

第二点：稳定，中台对业务有收益，最根本的是保证稳定，稳定是发展的前提和基础。

在整个构建中台的过程中非常重视稳定性，有各种机制，包括灰度发布、分层次发布、流量回放、全链路压测等等，保证代码的质量和系统的稳定。

第三点：加强沟通，平衡多业务的优先级。

滴滴出行有多个业务，有很多大区和城市，每个地方都有很多需求，要有一套机制和资源池。

如何保证相应每个业务都能按照所对应的在公司的重要性来获取部分资源，要保障它的灵活性和效率，所以要有很多沟通工作，有很多平衡的工作。

第四点：中台系统要不断演进，不能一成不变，要发现问题、解决问题。

业务中台不是一蹴而就，而是要在发展过程中不断的变化，持续迭代。

第五点： “没有最好，只有最合适”！

所有中台都一定是适合某个公司特点，最合适的中台是当你深入了解业务、产品、系统、组织，而且不仅了解今天在哪里，还要了解过去是怎么演变而来，未来又会怎么演化。

系统层：系统定位、系统架构、模块抽象、规划蓝图

系统层是指系统层面的一些东西，包括系统定位、系统架构、模块抽象、规划蓝图。人们看到体验到的产品都是露在外面的那一块，实际上还有很多系统在海平面以下，或大或小的产品背后总后好几套系统的存在。大的例如下图的唯品会，整个分为SAAS、PAAS和IAAS，每个里面有多个平台多个系统，才能支撑起唯品会的发展。小小的一款APP里的IM、推送等可能都是第三方提供的独立的系统。

唯品会的整体架构

 

系统定位

系统定位就是指确定系统要解决什么需求，先要有拆分出系统的需求，然后才有这个系统。系统定位必然是最先一步，并不是所有东西都要单独拉出个系统去做。观察大型系统的演进过程可以发现，绝大部分系统都是从初始的小功能到模块最后再到系统的（功能＜模块＜系统）。

系统化本身就是为了解决资源共享低、利用率低、不能集中处理等问题，系统也能降低整体耦合性，此时应该和架构师进行探讨，因为大部分都是技术层面的东西，要思考清楚哪些是系统哪些不是系统，所解决的需求是否重要是否急迫，并且对每个系统提出定位作为迭代方向，当然定位并不是一成不变的。

 

系统架构

确定了有哪些系统和对应的系统定位后，即可开始进行系统架构。系统架构强调的是系统和系统之间的联系，如果有多个系统还可以像唯品会一样平台化，便于理解也便于组织架构划分。

如果发现系统架构完成后，并没有把所有系统or模块包含进去，则要回到系统定位上重新梳理和思考，要把所有都包含进去。因为系统架构是解释系统之间的关系，绝对不能硬塞进一个模块。就像外出前收拾行李，把一堆东西塞进一个书包、一个旅行箱和一个编织袋，塞完了发现还剩一双鞋，得想办法塞到专门放鞋子得编织袋里面，但是编织袋已经满了也没法倒腾出空位，那就只能塞到旅行箱里面。

装满东西的旅行箱（来自百度图片）

系统和系统之间要协调配合，互相联系互相制约，就像运动系统、神经系统等八大系统使人体内各种复杂的生命活动能够正常进行。

 

模块抽象

平台、系统、模块和功能之间的关系应该是：平台包含系统，系统包含模块，模块包含功能。此处所讲的均不能只看做是前台的某个界面，均包含后台所对应的逻辑等，是一个立体的结构而不是前台的平面结构。平台、系统、模块和功能都是立体结构，只是粒度不同。而角色、实体和流程是平面结构，是不同角度下不同视野下的系统。

模块抽象就是指把不同模块都抽离出来，模块和模块之间互相独立互相依存，类似系统定位，划分了模块之后才能确定哪个系统包含哪些模块。

功能从场景和流程中抽象，模块从功能和实体中抽象。像唯品会等电商系统，会分商品模块、品类模块、订单模块、购物车模块、支付模块等等。一个模块包括前台的展示页面/组件+后台逻辑。模块的抽象是很自然的，因为本身系统的建立就有其内部的生态或者逻辑，就像人体的呼吸系统包含呼吸道（鼻腔、咽、喉、气管、支气管）和肺一系列器官以及内在逻辑。

 

规划蓝图

优秀的产品都是迭代和规划出来的，而不是一生下来就是。很多产品前期都是很简单很基础的几个模块，而且1.0版本用以快速试错的，如果模块很多体量很大就会浪费资源，要是失败了就得不偿失。

规划蓝图并不是计划蓝图，规划和计划的区别在于，规划是长远的（6个月以上）、不详细的、目标不精确的，计划则是短期的、详细的、目标精确的。例如，2018上半年要开发新版本就是个规划，而2018年6月前用户要自然增长100%通过优惠券、满减等手段则是计划。

在系统架构和模块抽象起来后，我会进行规划蓝图的工作。规划蓝图分两块，需求树和产品路线图，需求树是把所有需求（系统、模块、功能或者某些待解决的问题）放到树形图上，产品路线图则是把需求树上的需求经过筛减后按照产品阶段放置。

需求树示例

 

需求树，是为了梳理、分类需求，分析优先级和前后置条件。树根是实现整个系统所必须要的基础设施，树干是核心功能模块，树枝是可以进入的领域或者方向，树枝上也有功能模块。一开始先把核心功能、基础设施和方向领域确定好，然后用便利贴往上贴功能模块或者需求，最后按照越靠近主干越优先的策略调整便利贴的位置。期间整个团队都有一起合作，各抒己见，一起协商这些具体功能或者想法应该怎么发展，一起确定优先级。

需求树可随时补充，而且要定期把需求树上新增的需求删减、调整以放到路线图中。

产品路线图示例

产品路线图，是为了明确产品什么时候该做什么，是最多6个月到2年的产品路线，具体看公司规模、行业特点等。产品路线图可根据实际情况进行调整，但不是想要改就改的，产品路线图很严肃，不严肃的毫无意义，要遵守他。

路线图包括产品阶段、里程碑、需求。

产品开发阶段是指产品所处的阶段，会有初始、成长、成熟和衰退四大阶段，每个大阶段根据不同情况会有小阶段，视产品情况自行确定。处于不同阶段的产品都有不同的产品战略，要归纳出来，为需求的选择和实施方向提供思想支持。

里程碑主要是用来划分阶段的，例如找到第一个用户G点并形成可复制方案使得用户大规模增长，从初始进入了成长期；在新增和流失用户打平，做再多拉新活动ROI都会持续下降，从成长进入了成熟期等等。

基于产品阶段、阶段中的产品战略和需求树，把需求放到产品路线图中，最终形成产品路线图。离当前时间越近的要详细些，远的则大方向要清晰。

来源：Vency