建立维护商品库。业务流程如下图：
在线销售。业务流程如下图：
在线接龙。业务流程如下图：
资金结算。业务流程如下图：
该流程中，需要特别说明的是：
客户下单后支付的资金，是进入平台账户的。只有在客户确认订单收货、或系统超时自动确认收货（目前为 48 小时，要求系统可配置）后，才转入商家账户。在转入商家账户之前，系统会按笔自动扣除服务费（目前按千分之六比例，要求系统可配置）。
加盟商佣金的结算，也是类似的逻辑，只有在订单被确认后才进行。
账户提现流程中，并不是商家一发起系统就立即同步完成提现，而是考虑到常规的金融操作逻辑，一般采用 T+n 模式。目前 n 为 0（也就是当天提现，一般为几分钟内到账，视系统性能而定），并且不排除将来根据商户等级、商户分类等支持 n 为 1~7 之间的分级模式。因此，商户发起提现到后台完成提现是分开两步完成的。
账户充值，主要是考虑可能商家账户余额为零，但商家又开通了订单短信提醒这类收费服务。为了让收费服务能够正常使用，商家是需要自行充值的。
5服务蓝图和业务用例
在完成了业务场景和流程的设计之后（这两个工作应该是架构设计师或需求分析师的基础技能），就可以开始业务用例的识别的。个人以为，业务用例的识别使用“服务蓝图”是个很好的主意。因为服务蓝图按 3 个分割线：交互分割线、可见性分割线、内部可见性分割线（详情参见后面的实例介绍），将满足用户需求的整个过程从“前台服务”、“后台服务”、“后台支持”3 个角度进行了梳理，这将会是“最全面”的流程分析视角，能够保证不遗漏一些重要的“业务用例”。
鉴于“群买菜”系统的 6 个业务场景全部画“服务蓝图”、完成“业务用例识别”（其实是画“业务用例图”）的篇幅较大（在我的设计文档中，这部分占了 25 页篇幅），这里我就不一一展示分析过程，而只是就一个关键业务场景“在线销售”进行了解读，并将所有场景下的“业务用例图”给出来。
基于上一小节中“在线销售”的业务流程图，我画出如下的“在线销售服务蓝图”：
以该“服务蓝图”为样板，我稍微介绍下“服务蓝图”的相关概念和设计方法：
交互分割线。交互分割线一般用于客户（可能是机器人）和一线服务人员（也有可能是机器人）之间的一个边界线。在“交互性分割线”之后的操作，我们一般称之为“前台”操作。对于有真人作为一线服务人员的情况来说（比如：营业员、柜员、客服坐席等），交互分割线就分割了用户和一线服务人员之间的“交互边界”（如：提出要求、交身份证、回答提问等等），前台操作是由营业员等完成的；对于客户通过网站或 app 自助进行服务的情况下，大部分情况下，前台的操作是由客户自行完成的，这时候前台操作就认为不存在。
可见性分割线。可见性分割线一般是前台操作人员和后台服务人员之间的分割线。在“可见性分割线”之后，往往是后台服务人员（如：审核人员、财务人员等）。对于有真人作为一线服务人员的情况来说，可见性分割线就是客户看到一线服务人员在操作的内容（比如：看到营业员在操作电脑、收款等）；对于客户通过网站或 app 自助进行服务的情况下，大部分情况下，前台的操作是由客户自行完成的，这时候会使得“交互分割线”和“可见性分割线”变成一条线。
内部交互分割线。在“可见性分割线”之后的是“后台服务性工作”，而在“内部交互分割线”后面的是“后台支撑性工作”。一般来说，“后台支撑”并不对客户服务产生直接的影响，而是“提前”或“滞后”影响的，如：电商业务中维护商品库、每日盘点库存等。
下面我对“群买菜”在线销售“服务蓝图”的一些内容做特别说明如下：
前台操作中，除了客户自助完成的“商品浏览”、“在线下单”和“确认订单完成”外，其实是“商家”一线服务人员给“客户”的服务内容。在“群买菜”小程序为客户提供自助浏览商品和下单的基础上，其实“商家”一线服务人员能干的工作，就只有：在微信群分享或私聊“发送小程序店铺（或商品）链接给客户”、为客户备货后的“多退少补”、以及客户要求退货时的“退货退款”。
后台服务性操作中，一部分由伴生系统“微信支付平台”完成：创建预支付、完成支付转账、触发群买菜服务器生效订单；一部分由商家人工完成：备货、发货。
后台支撑性操作中，商家人工操作的，只有“维护商品库”；而“超时自动取消订单”、“超时自动完成订单”是电商系统的常规性操作，都是系统机器人自动完成。
而关于“每天自动恢复上架商品有货”我们需要特别解释下：这是一种简化的“库存盘点”机制——考虑到“生鲜”类商品，大部分是每日进货的，而系统并不打算支撑完整的“库存管理”（为了确保在线库存量的准确，在生鲜行业这是一个极其复杂的过程，需要每天进货后对所有货物的实际斤两进行准确盘点，并在每次线下销售后对售出斤两在系统中“进行准确扣减”，而对于“个体生鲜店”来说，人工投入少，这是不现实的），所以就采用了简单的方案：一旦商家备货时发现商品库存不足、就主动给客户退款并标注商品“售罄”。但问题又来了：如果店里有 200 个 SKU，每天售罄约 60%就是 120 个 SKU，在次日开业前如果让商家对这些已售罄的 SKU 手动标注为“有货”，就是个很繁琐的操作——为此，我们开发了一个系统机器人执行的“每天自动恢复上架商品有货”功能。
有了上图的“服务蓝图”，我们就能对“在线销售”场景识别出如下的业务用例图：
需要注意的是：这里的“用户管理”、“客户进店”、“客户购买”等用例分组，并不是严格意义的系统模块分组，这里只是为了理解方便而暂时做的分组。
在该业务用例图中，我对某些业务用例的特殊考虑，说明如下：
服务蓝图“客户下单”环节用到的商品管理相关业务用例说明：
- “维护商品库”就是由“建立商品库”场景中相应的“商品管理”模块的业务用例来满足需求的；
- 每天自动恢复上架商品有货。这个业务用例，前面已经说过了，不再赘述。
“客户进店”用例分组中，有 4 个业务用例需特别说明：
- 分享店铺或商品到微信。这里我们根据产品经理提供的 UI 设计要求，系统是允许商家的授权操作人分享整个店铺、或单个商品页面两种方式到微信群或私聊的。
- 系统自动定位店铺。有些情况下，客户可能是直接通过在微信平台搜索群买菜小程序进入系统的，这种情况下系统将自动根据客户的最近浏览历史、当前手机定位、店铺创建历史等信息，来为其推荐最合适的店铺来打开群买菜小程序。
- 搜索店铺。与上一个用例相对应的，由于系统默认打开的店铺可能不是客户想要看的店铺，故系统支持客户自行搜索店铺。搜索结果将以列表方式显示给客户，供客户选择。
- 查看店铺详情。客户也可以通过点击当前页面上显示的店铺进入查看店铺的详情情况，包括店铺门头图片、联系人和联系电话、以及支持通过微信自带的腾讯地图导航到该店铺位置。
“客户购买”用例分组中，相关业务用例的特别说明如下：
- 浏览店铺商品、搜索店铺商品、查看商品详情，这 3 个业务用例对应服务蓝图中的“浏览商品”环节。
- 加商品到购物车、确定订单付款，这 2 个业务用例对应服务蓝图的“选购并确认付款”环节。
- 获取微信绑定手机号。这是在确定订单付款时，需要用户填写联系手机号，为了方便用户而允许用户直接点击按钮获取用户绑定微信的手机号。同样因为涉及到微信平台这一伴生系统，故独立提出该用例。
- 创建订单预支付、完成订单支付。这是微信支付系统已经提供的功能，本系统只是集成该系统已经提供的开放能力，按照微信支付开放接口规范实现即可。需要明确的是，按照微信支付规范，需要先在系统后台调用微信支付系统接口创建预支付流水号、然后返回给前端小程序界面提示用户进行支付密码验证（或其它验证方式）后，微信支付系统“完成支付”，并调用本系统提供的开放接口（即“生效订单”用例）。
- 生效订单。该业务用例是供微信支付系统在用户支付成功后，反向调用本系统的接口。在该接口的实现中，需要记录订单为已支付状态，并且需要特别说明的是：如果客户下单的商品中包含有商家上架到自家店铺、但是从品牌商导入的商品，则系统需要根据订单内容为品牌商创建子订单。子订单存在的目的，主要是为了用于两个场合：1）根据子订单为品牌商结算营业收入；2）根据子订单为加盟商结算佣金收入。
- 超时自动取消订单。在客户填写好收货信息（选择收货方式是到店自提还是送货上门、以及送货上门地址、联系手机号等）后，确认对订单付款、微信弹出支付页面后，如果客户超过一定的时限（默认 60 分钟）没有付款，则订单自动取消。这么设计的目的，是因为商家可能在收到订单提醒后（虽然客户可能还没有完成付款），就会开始备货。如果客户不能最终支付，商家则需要将备好的货物再放回实体货架方便继续销售。
- 浏览我的订单、查看订单详情，这两个业务用例，不在服务蓝图中有体现。但在实际电商交易类系统中，这两个是必不可少的业务用例，是为了方便客户随时查阅自己下单后的相关信息的 。同时，这两个业务用例也是客户进入后续“确认订单完成”用例的操作入口。
- 确认订单完成。客户收到商品实物后，确认订单完成。在操作确认之前，客户可能会联系商家要求退货退款。只有订单被确认完成后，商家才能最终收到平台转账的营业收入。在订单确认完成时，如果订单包含了品牌商的商品，则系统需要自动同步完成所有品牌商子订单（可能有多个）的确认。
- 超时自动确认订单完成。正常情况下，客户在收到货物后，需要对订单确认收货，系统才允许商家将该笔订单的营业收入进行提现。但如果客户没有进行手动确认操作，则系统将会在超过最大超时时限（默认 48 小时）后，由机器人自动确认完成订单。同样，自动确认完成订单时，如果订单包含了品牌商的子订单，则同步完成所有品牌商子订单（可能有多个）的确认。
“订单管理”用例分组中，有 4 个业务用例需特别说明：
- 发送订单提醒。会有如下几个场合，系统后台机器人会给相应的对象发送订单提醒：
- 客户在系统下单完成（即付款完成后），系统会给客户和商家发送订单提醒。对客户来说这只是个提醒，而对商家来说这是业务价值的关键一环（故商家消息是可点击链接打开小程序查看订单详情的）：为了方便商家及时响应客户需求，因为如果不及时响应线上订单备货，可能线下有客户就将相应的货物购完，而线上客户最终没有库存可供发货。按照销售的“先到先得”原则，应该是谁先付款谁先拿货。为此，需要系统自动给商家及时发送订单消息提醒。
- 商家备货完成后，会给客户发送订单纯文本消息提醒（无 UI 操作要求）。
- 商家发货完成后，会给客户发送订单纯文本消息提醒（无 UI 操作要求）。
- 商家退款完成后，会给客户发送订单纯文本消息提醒（无 UI 操作要求）。
- 商家补收货款时，会给客户发送超链接消息提醒，可点击该消息后打开小程序进行付款（事实上，用户也可扫商家小程序端提供的二维码补款）。
- 客户确认订单关闭、或系统超时自动关闭订单时，系统机器人会给客户和商家双方发送订单提醒。给客户发送的是纯文本提醒，给商家发送的是可点击链接打开小程序查看订单详情的消息。
- 订单提醒方式的设计，考虑到早期平台的运营成本问题、以及微信平台的限制，只支持两种方式：1）微信公众号免费提醒；2）在商家的小程序管理后台界面的订单管理界面上，会有“未读红点”提示。将来新版系统会为商家提供 PC 端管理后台，会在 PC 端进行语音播报。
- 记录订单备注。有些情况下，商家可能需要对客户订单特殊备注，比如：客户要求先备货、到下班回家后才来提货或送货上门等等。这种情况下，就需要系统为商家提供针对某订单的特殊备注说明。
- 管理客户信息。为了能够给客户提供售后服务、以及某些情况下方便商家服务客户，商家需要了解客户的一些基本信息（如：客户姓名、性别、电话、标签、自定义等级等）。因为微信提供的往往是网络昵称，而这往往是不够识别客户身份的。所以，事实上需要目标系统为商家提供客户基本信息的管理功能。
- 操作订单备货。在商家为客户订单备货的过程中，可能存在某些货物已经缺货，这种情况下需要系统支持同步将商品设置为无货状态。
- 补收客户货款。
- 生鲜是个特殊类别的商品，很多商品的规格并不标准化，尤其是活鲜类商品。这种情况下，类似活鲜类商品又是按斤销售的、但其重量又因为成品大小不一，无法准确在线上给出价格。为此，系统需要支持多退少补功能。对于“少补”的情况，需要系统支持商家在客户到店自提、或送货上门时，系统自动生成收款二维码，让客户补付差额部分。
- 如果补收货款的商品中包含品牌商品，则需要进行品牌商子订单补款操作。
- 退客户货款。
- 退客户货款用例，会使用在三个场合：1）“多退少补”情况下的“多退”；2）商家备货时，发现某个商品已经缺货，主动给客户退款；3）客户要求退货时商家退款给客户。
- 如果退款的商品中包含品牌商品，则需要进行品牌商子订单的退款操作。
下面我将其它 5 个业务场景下所有的“业务用例图”截图如下：
“建立店铺”业务场景对应的业务用例图：
“加盟品牌”业务场景对应的业务用例图：
“建立商品库”业务场景对应的业务用例图：
“在线接龙”业务场景对应的业务用例图：
“资金结算”业务场景对应的业务用例图：
上面我们已经深入地展示了如何设计“服务蓝图”、并基于此给出“业务用例图”设计。在 DDD 全局分析中（也可以理解为需求分析），其实还有个特别重要的工作，就是对每个“业务用例”给出“用例规格书”——相当于是需求规格书。由于篇幅内容过多，而且比较适合放在 scrum 敏捷迭代的每个冲刺（sprint）中，故这里只是给出一个示例（备注：“业务用例”也叫“业务服务”，故下图中的“服务编号”其实就是“业务用例编号”）：
6业务子域识别和分类
终于到了本节的最后一个内容：根据业务用例的识别，对目标系统的业务子域进行识别和分类。下图是我对“群买菜”各业务子域的识别和分类结果：
对这个识别及分类结果，说明如下：
系统子领域的识别，要从系统的核心价值出发。正如前面的“价值需求规格书”所说：该系统的愿景是：通过为生鲜店老板/社群团长提供在线零售、在线接龙、加盟分销三大主要业务所需功能的微信小程序，让尽可能多的生鲜店和团购社团使用，平台方赚取系统服务费和资金沉淀收入。
目标系统主要涉及到三大类利益干系人：生鲜店或社群（商家）、消费者（客户）、平台运营方。
我们分别从三大类利益干系人来看。对于商家来说，分别从三大业务线来看：
- 在线零售业务，从传统的电商系统设计来看，需要目标系统最起码提供商品库管理、订单管理、客户管理几个主要核心功能域。
- 在线接龙业务，需要目标系统提供接龙管理、订单管理、客户管理几个主要业务功能域。
- 加盟分销业务，需要目标系统提供加盟关系管理、加盟佣金结算几个主要业务功能域。
对于消费者（客户）来说，主要涉及的功能域是在线选购和下单（可属于订单管理）、查询/查看自身所下订单的信息和状态（仍可属订单管理）、手机支付。
对于平台运营方来说，主要涉及的功能域有：商家管理（主要是用来识别店铺的收支结算到哪个账户下）、平台资金结算这两个业务功能域。
上述所有功能域汇总起来有：店铺管理、商品库管理、订单管理、客户管理、接龙管理、加盟关系管理、加盟佣金结算、手机支付、商家管理、平台资金结算合计 10 个功能域。其中，我们可以把加盟佣金结算和平台资金结算合并为资金结算，这样最终就是 9 个功能域。这 9 个功能域中，手机支付属于微信平台的功能，应该属于通用子域。剩下的其它 8 个我们需要识别其是核心子域还是支撑子域。
所谓“核心子域”其实就是目标系统的“核心价值所在”，这就又回到了目标系统的商业价值识别上去：
首先，系统愿景中“让尽可能多的生鲜店和团购社团使用，赚取系统服务费和资金沉淀收入”这句话就点出了目标系统的核心价值就是让平台有尽可能多的订单产生、以尽可能多的产生系统服务费和资金沉淀。因此，我们可以很明显的识别出：“订单管理”、“资金结算”必须是核心子域。
其次，考虑到“群买菜”其实主要是为了和目前市面上的通用类接龙软件如“群接龙”之类的区分开来、突出生鲜行业的特点，所以“商品库管理”也是目标系统的“差异化价值所在”，故将“商品库管理”也识别为核心子域。
最后，我们为了让“群买菜”产生尽可能多的订单，就必须要有足够多的“商家”。而产生足够多商家除了在软件产品设计上简洁易用之外，还要求有一些“硬性的”能够帮助目标系统快速“病毒式传播”的特性。而根据“群买菜”产品原型中给出设计方案，我们可知：其“加盟管理”其实就是为了实现一种“轻连锁”和“轻加盟”方式，使得本城的“中型生鲜连锁”也能够使用目标系统（无论是加盟还是直营模式）、以及“生鲜社区店”之间因为可方便快捷的“共享优质生鲜货源”而帮助“群买菜”进行“病毒式传播”。为此，我们认为“加盟管理”也是目标系统的“核心价值所在”。
因此，我们得出的核心子域包括 4 个：“商品库管理”、“订单管理”、“加盟管理”、“资金结算”。
其实，我们还有另一个角度可以判断哪些是核心子域——即从商业角度来说，我们“不愿意外包给别人开发”的部分有哪些？我理解，所谓的“不愿意外包给别人开发”其实就是“商业机密”，也就是不想让组织外部的人“弄清楚我们是怎么玩、以致于可以在商场上攻击我们”的那些部分。从这个角度来说，我认为将“商品库管理”、“订单管理”、“加盟管理”、“资金结算”4 个部分保护起来不让外人知道，也是合理的。
另外，对商家来说，考虑到工作很杂，可能还会允许多个微信账号对店铺进行操作，故需要系统支持员工管理。考虑到该员工管理仅限于对目标系统的商家下微信账号做简单管理，不打算做到各行业通用的、一个复杂完善的员工管理体系，故认为其属于支撑子域。同时，目标系统本来就要对登录权限进行控制和用户身份识别，故用户与授权也是必不可少的功能域，该功能域属于通用子域。最后，考虑到为商家提供订单提醒等，我们还需加入消息子域，该子域也是由微信公众号平台、以及用短信通知实现，属于跟具体行业无关，故也认为是通用子域。
到此为止，本专题系列完成了第 3 篇，算是完成了“群买菜”的全局分析（也就是需求分析）过程，也就是完成了“问题空间”的分析。在后面的章节中，我们开始致力于“解空间”的映射。那将包括：战略设计、战术设计、代码实现 3 个部分，才是本专题系列中占最多篇幅的内容。
