管中窥豹——从限购业务模型设计论产品业务模型构建之道

产品业务模型，是整个产品的核心模型。好的业务模型，可以通过对日常业务的抽象形成基本要素，通过对要素的再组合，在满足现有业务的情况下，预见中长期的业务创新。

为什么有些产品经理，经常能预见业务方的需求了？因为日常的产品需求，大多数是原有要素的排列组合，或者在原有基础上加入部分新的要素（对原有模型的丰富）。因此对于产品经理来说，整理出一个好的业务模型，并用它来指导工作，可以批量解决大部分的日常需求，同时底层的业务架构会更加明晰，尽可能减少对系统打补丁的情况。接下来，我们就来看看，如何搭建一个完善的业务模型吧！

一、组成——产品业务模型构成

产品的业务模型是业务的抽象模型，包括从底层的业务对象，业务范围、业务限制、业务规则等、执行层的数据流动方式及展现层的前台展现交互的设计。一个较为通用的业务模型模板，可以由架构层，数据层，展现层三层构成。其中各层的主要内容为：

• 架构层：业务对象、业务范围、业务规则等；
• 实现层：产品的数据流动，及技术实现的流程；
• 展现层：交互设计，边际条件设计，空白、报错提示等。

二、准备——深入了解业务

业务模型最难设计的部分，也是最底层的部分，当属业务架构层。要设计好业务模型，需要对业务具备一定的了解。

对业务的了解，可以分为3个部分，分别是对业务背景的了解，对业务本质的了解，以及对业务边界的了解。下面，以交易中的一个简单功能，限购，进行举例。

01 对业务背景的了解

限购业务产生的背景主要有二：

a.特价商品，让利过大： 这个业务刚开始，是源于商家进行限时特价，拉新让利。商家进行相关营销的目的是，通过让利，刺激拉新及留存。这就需要尽可能多的让新用户及老用户能够享受到让利。

然而实际操作过程中可能出现的三种损害商家利益的情况： 一些用户拍得过多，影响其他客户的购买； 一些用户恶意拍光库存让活动商品下架（恶拍）； 拍光低价商品，然后到平台进行倒卖，冲击市场价格。

为了限制这部分胃口过大用户，恶意用户及羊毛党，商家有了对用户购买件数限制的需求。这是需求的起源。

后续随着营销业务的发展，平台开始发展出了低价试用或者包邮试用的业务。这些业务的营销方式，是低价（接近免费）的进行新用户触达，因此和限时折扣一致，会面临同样的问题，因此归为一类。

b.热门商品，库存有限： 商家只能拿到限量的热门商品，然而该部分商品库存有限，不足以支持开放购买。为了让顾客尽可能公平地购买，需要进行限制。

以上两种情形，是目前商家进行限购的主要场景。

而平台也有使用限购的场景，比如对特定的用户允许购买让利商品。由于平台面对的用户量更大，无法一一满足，只能选择扩大触达覆盖率的方式，因此也会限购。原因与商家进行限购的原因大同小异。因此限购这个业务，不仅是商家的要求，还是平台的要求。

02 对业务本质的了解

从上面的业务演变中，我们可以看出限购业务的本质。

a.限购的前提之一是稀缺性

稀缺性的本质是供求关系不匹配中的一种——供不应求。稀缺性由商品价格与行业价格的落差，以及库存的数量体现。一双普通的乔丹鞋，理论上是没有稀缺性的，但如果一双乔丹鞋在保证正品的情况下，只卖100块，大大低于行业价格，那就具有了价格上的稀缺性；或者推出全球限量款，只制作5双，而有10000人想买，就具有了库存上的稀缺性。没有稀缺性，就无需限购。

b.限购的目的是提高同等数量商品对特定用户的触达率

从需求背景我们可以看出，限购的目的，并不是让用户减少购买，而是通过限制个人购买的方式提高同等数量商品对特定用户的触达率。

因此我个人对限购业务本质的理解是： 限购是由于资源稀缺，商家或平台通过限制用户的购买行为，以提高同等数量商品对特定用户触达率的行为。

03 对业务边界的了解

业务边界，换个说法就是，由谁来做，由谁来维护？

其实，限制购买是个比较宽泛的概念，可以有多重理解。理论上，对用户任何的购买行为进行限制，都属于限制购买。简单举例：

1. 至少购买2件，和至多购买n件，都是限制购买的概念，需要整合一起做么？
2. 至多购买0件，就是禁止下单，涉及到风控的业务，需要与风控整合一起做么？
3. 如果限制购买数量（前100享受优惠价，然后恢复原价）的话，会涉及到库存分割的概念，需要整合在商品平台中的库存中心一起做么？
4. 限购与限时折扣相关的话，其中限购价格是否需要考虑？考虑的话是否要由促销的同学来做呢？

限购的边界在哪里？以上三个例子，涉及风控，促销，价格，库存，交易等多个不同环节。这个问题没有明确好，就容易造成业务划分不清晰，功能不明确。

针对以上问题，我是这么看的：

1. 至少购买2件，是为了提高客单价的促销考虑，目的是增加客件数及客单价，因此应该放在促销，促销的落地点在销量，而限购只是提高触达率，对销量没有直观的提高作用，甚至还有阻碍作用；同时有部分非促销的场景也需要用到限购工具（如库存问题导致的限购），因此不属于促销，因此也不放在促销、价格相关的设计中，否则会加大促销模块的维护成本；
2. 业务边界需要根据业务本质来制定。限购是处于营销或者交易公平的考虑，进行的限制，因此风控需要被排除。也就是禁止下单的功能，风控需要自己做，否则后续业务与风控耦合会越来越紧，导致限购功能尾大不掉；
3. 限量一般来说是前XX件，本质上也属于通过阶梯价的方式进行促销，因此也不放在限购中考虑；
4. 价格是商品和促销的一部分，在库存限制的场景中，价格的变动与限制购买关系不大。

因此，既不在风控、促销、价格、商品等模块中，那应该归结到哪里呢？

个人认为，放在交易是比较好的选择。 放在交易的原因，是因为限购的场景可能部分是在风控、促销、价格、商品等模块中，但所有的限购场景都是在交易中落地。因此限购，应该是交易的业务，主要服务于交易。其他业务有临时的业务需要，来进行调用即可。

三、架构搭建——产品业务模型搭建方法

我们在对业务有较为深入的了解之后，我们就可以着手搭建我们的产品模型了。在搭建产品模型这一点上，我的方法论是： 厚-薄-厚 ，下面我们开始着手进行模型搭建。

第一个厚，是指遍历业务场景；薄是指抽象业务元素，建立业务模型；第二个厚，是指将建立的业务模型重新返回业务中进行校验。

还是以限购为例。我们来看看如何通过厚—薄-厚建立业务模型。

首先，我们来看下，限购的具体的业务场景： 购买过某些类目商品的用户，每个ID限购限量玩具n件；

购买特定活动店铺的用户，每个ID限购限量玩具n件；

来自返利渠道的用户，每个ID限购限量玩具n件；

APP用户可以购买每个ID限购限量玩具n件；

仅限APP上，使用微信支付的用户，每个ID限购限量玩具n件；

……

这么多的场景，穷举得完么？（偷偷插一句，这就是日常需求的来源=。=）

让我们来造个句子。 限制购买商品。

记下来，我们来完善下这个句子，用填充定语的形式进行补充： 限制（参加特定活动的）（特定来源）的（特定用户）（在特定时间）（在特定地点）（以特定支付方式）（以特定规则）购买（特定数量的）（特定商品）。

那么接下来，我们就可以按照这个逻辑进行梳理。

这就是第一个阶段。我们在这个阶段，尽可能把所有涉及到的要素都进行穷举。穷举之后，其中各个部分可以进行自由组合。我们可以通过这个方式遍历大部分的业务场景，最高效地找出之前遗漏的场景。

好，那我们接下来看下，如何进行最关键的薄的转化（这其中需要对上面的定语再进行一次抽象，将相同属性的定语进行归类）。这么做的目的，是再找出这些定语之间的共性。目的是后续架构拓展可以以业务元素为维度进行拓展，无需为新增的定语打补丁。这提供了更大的拓展空间。

以限购为例，我主要分为限购时间，限购范围，限购对象，限购方式，限购规则这几个方式。这真正构成了业务元素。 薄的这一层，需要多次调整才能将所有的业务元素尽可能地放到合适的属性中。不过做完之后，长征路上就已经完成了50%了！

接下来是验证的厚了。这时候，我们会把之前的场景，都放到业务模型初稿中，进行试验，看通过模型能够实现这些场景功能，满足需求；然后再看看能不能通过整理的业务元素的再组合，实现目前有可能实现，但还未提出的需求（也就是传说中的预测需求的部分啦~）

如果以上两点都验证完毕，那恭喜你初步建立了自己的业务模型！这时候就可以拿着这个模型，与团队的同学们讨论一下，是否有遗漏的点，是否有可以调整的地方。如果大家都觉得模型没有问题，那么就可以进入到下面的环节，数据层模型的搭建以及展现层的表现设计环节。

因为内容较多，因此分为两篇呈现，下一篇会数据层模型的搭建、展现层的表现设计，以及业务模型的应用及局限，比心~！

 

本文由 @启辰菌 原创发布于人人都是产品经理。未经许可，禁止转载。