毕加索画过一幅画，目的是找出究竟哪些特征，能够让我们认出这幅画是一头公牛。
这幅图先后经历了：去立体化——去光影——去配色——去立体化——直至最后完全线条化等一系列过程，最后只保留了“牛角、躯干、尾巴、生殖器、四肢、以及地面投影”，这就是毕加索抽象的结果。这个抽象的过程凝聚了毕加索的深度思考，他用这6个元素，向我们描述和解释了我们的大脑是依据什么来判断“这幅画是一头公牛”这个信息，并且这6个元素再去除任意一个都会影响我们的判断。
业务抽象
理解了毕加索的这幅画之后，我们再说业务抽象。如果把“哪些特征能让我们认出这幅画是一头公牛”当做是业务的话，画中保留的最后6个元素就是抽象结果。可以说，毕加索用这6个元素创建了一个“什么是公牛画”的认知模型。
所以业务抽象的过程，实质上就是面向现实世界的不同“场景”进行建模的过程（或者说直接是面向“世界”进行建模）。它用高度概括性、结构化的内容来描述了这种场景最核心的本质是什么。比如常见的SWOT分析法、波特五力模型，这些都是面对“企业应该如何发展”这个场景进行描述的模型；《用户体验要素》是对“网站产品设计流程”这个场景进行描述的模型。
但是在做实际业务过程中，现成的模型通常很难全面概括业务，所以经常需要自行建模。在面对同样场景的业务的时候，竞争者之间第一个差距就体现在“建模”能力的差异，谁的模型描述更接近场景的真实核心本质（参考毕加索公牛画的抽象过程），谁的机会就更大。
我们生活中其实处处存在着建模：
- 电商是对交易建模
- 推荐系统是对行为习惯建模
- Ai是对大脑建模
- ……
曾经的互联网三座大山之所以能成为三座大山，也是因为：
- 百度的“信息”建模，对“人与信息”的关系解释的最好（现在移动端是字节解释的最好）
- 阿里的“交易”建模，对“人与商品”的关系解释的最好（就在大家都以为阿里，京东和美团已经是交易模型最优解释的时候，拼多多又提出了新的解法）
- 腾讯的“关系”建模，对“人与人”的关系解释的最好
但任何模型对现实世界的解释都是存在边界的，所以支付宝做不好社交，不是产品不努力，是从“支付”模型很难过渡到“人际关系”模型（现实世界中，每次人际交流都要先打开钱包进行支付的行为，你能想到什么？对，它违法啊……）；而微信通过红包做支付就很顺，因为从“人际关系”模型过渡到“人情交际”模型很顺，但是想继续过渡到“交易”模型又不够顺，至少是不如字节从“信息”过渡到“交易”这个模型顺。经常有人挂在嘴边的xx公司不具备做xx的基因，也可以通过“建模解释边界”来理解为什么不具备这个基因。
所以最后再总结一下什么是业务抽象：它是一个建模的过程，是通过模型对现实世界的场景进行描述和解释的过程。
抽象建模是产品设计中的一个很重要思路，它能帮助我们将一些看似没有任何规律的业务进行一个标准化，就拿我们产品经理来说，现在相信大家都知道产品经理的工作流程是如下的这几步：
用户访谈、分析用户场景、梳理需求优先级、需求版本规划、需求设计、需求评审。
但是大家有没有想过是谁当初第一个提出这样的标准工作流程？这样的人就很厉害了。
那么说了这么多，到底抽象建模的本质是什么？一句话来概括就是：业务组件提取。
所谓业务组件提取，就是指我们在进行业务分析过程中，不断将业务划分成若干个小的组件与模块。例如我们可以将电商系统划分为商品中心、订单、支付、物流、会员这五大组件，通过这五大组件共组建起了一个完整的电商系统。
那么在这过程中我们将一个完整的在网上下单购物的流程拆分成这五大部分就是一个业务组件的提取，当然，这里的又组建提取并不是只是在系统层面的划分，我们很多时候在产品内部设计的时候也会遇到很多业务组件的提取。
业务模型是对现实世界的抽象，而不是对现实世界的枚举。抽象得好的业务模型是简洁清晰的，一看就明白的。而枚举出来的数据模型是复杂，晦涩难懂的。如果一个模型很复杂，多半是对大量业务场景的枚举，而不是抽象。实际应用中，抽象模型的每一部分都会得到应用，而在枚举的业务模型中，你会发现很多内容只在很少的应用场景下才会使用，甚至在软件的整个生命周期中都没有得到应用。
假设我们要设计一个在线教育平台APP，首先分析这个教育平台的系统框架，我们会发现在这里本质上就是要对三个对象进行管理，如下图所示：
- 课程资讯：实时推送最新资讯；
- 课程电商：显示出售的课程；
- 学生题库：供学生选择适合自己的习题册进行练习。
面对这样的一个需求，我们想一想平时我们会怎么样去进行产品设计？
我相信绝大多数的产品经理都会按照将这三个对象视为三个完全不同的模块进行独立的信息架构与页面结构进行产品设计，例如设计资讯中心时的思考路径如下：
那么如果用组件化的思维来进行思考的话，我们其实可以完全去将这三个对象视为三组数据，那么站在数据视角上来看，此时我们需要设计的产品实际上就是为这些数据去寻找可以承载的组件。
那么这个时候，我们就可以得出这些数据都有如下三类承载需求：
- 信息分类选择的需求：划分不同功能入口；
- 集合类展示的需求：列表展示多个对象个体以供选择；
- 个体类展示的需求：展示详情。
这样我们就将看似毫无关联的三个对象抽取出了一个标准的页面组织架构，也就是：
按照这样的设计结构，我们就可以将这三个数据对象。定义为如下的数据组织：
集合类数据：
集合1：
- 课程资讯集合
- 资讯记录集合
集合2：
- 课程电商集合
- 课程记录集合
集合3：
- 学生题库集合
- 题库记录集合
对象实例数据：
- 本条记录的数据摘要；
- 本条记录的数据属性；
- 本条记录的数据详情；
根据这样的数据结构，我们就能得出最终的产出：
我们可以看到通过这样的设计，我们成功的将这三类对象合并到了一套程序组件载体中，此时如果我们需要进行迭代，只需要调整一次三个数据对象都会发生改变，大大节省了开发人力。此外这样的设计也让后台系统在某种意义上只需要进行数据源格式的不同管理即可，而数据接口等都可以高度复用。
那么我们再设想一下，如果没有按照这样的页面组织架构进行产品设计会遇到什么样的问题？
首先我们对这三个对象需要定义完全不同的跳转路径，需要维护各自相互独立的页面结构与路径，导致我们需要对这三类数据在前台维护三组不同的页面代码。
在后台则对于这三组对象我们还需要有不同的表结构、数据接口以及数据消息体格式，因此很多时候开发的工作量就是因为很多产品经理在设计功能模块的时候没有按组件进行规划，导致增加了整个系统的开发成本。
文章部分内容转载：http://www.woshipm.com/pd/3493618.html