背景

我们首先要明确建模的目的，只要是软件系统架构，都不可避免的会腐化，我们可以通过多种方式来降低系统的腐化速度，比如合理的架构，良好代码的规范等等。

业务领域建模也是其中的一种，它可以根据业务来划分领域，划清业务界限上下文，统一产研对系统业务的认识和理解，减少多方在业务交互中的边界沟通的成本，同时呢也为了避免因为我们业务的耦合导致系统架构进入大泥团模式，坠入单体的地狱。

领域建模的思想对于单体架构演进至微服务架构是至关重要的思想策略

这里我就以商品系统为案例，讲一下在商品如何运用领域建模的方法，来完成向微服务领域的演进策略指导。

O2O商品系统模式

站在020的大的场景下，商家的组织架构大多书分为两种，我们的平台商品维度也对应两种：

• 商家-门店模式
• 独立门店模式

对应到商品上，必然也是需要商家商品-门店商品或者单纯的门店商品维度，从适用性来说，商家商品-门店商品两个维度是能完全兼容所有业务场景的。

那么对于商品系统来说，这两种维度有什么区别呢？

这两个维度的区别在于

• 商家商品-门店商品能否单独编辑
• 商家商品和门店商品的关系如何建立

各大厂商品架构模式的对比

对比各大厂平台的商品系统架构模式：

• 饿了么： 饿了么的商品架构模式一开始就是商家商品-门店商品维度，商家商品和门店商品信息都可以编辑、也可以很灵活的建立关系；

• 美团：美团一开始只有门店维度商品，没有商家维度商品，近期补全了这个痛点；

• 京东到家：商品架构一开始就是商家商品-门店商品维度，但是由于服务商超，门店商品无法编辑，商家商品-门店商品的关联关系也是强制绑定，在短期是适合业务发展且成本低，但是坏处就是扩展性太差，不适用小店也不适用其他业态。

我们这里就以通用的商家-门店模式来讲一下具体怎么实现商品系统的架构搭建：

1、商家首先在商品系统创建出商家维度的 SKU，创建成功后，商品系统发出消息通知，库存和价格这两个系统接收到消息后，会结合商家下的门店进行门店商品的初始化创建流程，也就是说，门店维度的sku，是继承自商品系统，一个商家下有多少SKU，门店下就会有多少SKU。

2、门店商品的名称、状态都源自于商家维度的商品信息。

3、门店商品库存系统，负责维护门店商品的库存数量、以及门店维度的商品是否可售。

4、价格系统则负责维护门店商品的价格。

这种商家-门店商品模式的好处是什么呢？

• 方便统一管理商品：这种模式的好处之一是方便商家统一修改商品属性，满足了连锁大ka，统一规范所有子门店商品的信息。
• 方便连锁KA对接：很多连锁KA都是商家管理子门店的设计模式，方便对接平台。

这种商家-门店商品模式的弊端是什么呢？

• 门店会冗余商家的所有商品：所有的商家门店会继承所有商品，无论门店售卖不售卖
• 增加门店的商品管理复杂度

作为O2O平台的商品系统，针对商家-门店商品模式，我们是设计成两套商品系统呢？还是设计成一套商品系统？

答案肯定是一个

因为商家商品属于整个链路的源头，所以商品系统包含了关于商品基础信息的所有业务整合，比如商品的建品、审核、治理、拓品、标库、图库等业务模块。如果设计成2套只会增加系统之间的复杂度，那么商品领域里的业务都包含哪些呢？接下来我们会详细解答一下。

商品系统建模

首先来看商品系统在电商业务中的定位，在电商领域里，商品是电商业务的开端，订单是电商业务的结果，商品在整个电商业务中，都占据核心的C位。从这张图里可以看到，一个商家从最初的入驻平台开始，经历商品建品、库存价格维护等一系列操作，直到商品上架售卖，运营和商家再结合上游其他系统比如cms搭建，通过楼层、lbs地址围栏、活动来配置商品，最后用户通过APP首页、搜索、门店商品列表页、单品页发现商品，通过购物车加车、提单支付环节最终生成订单，你会发现这其中的每一个环节都有商品数据的流转和支撑。

而且随着商品业务模块的增加，业务需求迭代也在持续增加

• 代码越来越大，开发周期变成
• 测试难度越来越大
• 商品内部模块与模块之间开始耦合，业务界限越来越模糊
• 产品交付的周期也逐渐拉长。
• 务的交互越来越多，耦合在一起就开始因为各自特殊的需求产生分歧
• 稳定性问题

在对商品系统建模之前，首先我们要识别出业务模块所在的业务领域中的特点是什么？那么怎么识别这些特点呢？

6W领域场景分析

采用了领域场景分析的6W来进行业务领域特点的提炼。

以商品系统举例，看这个时序图。

• 通过拓品业务，提供商品的拓品数据。
• 标库对拓品数据进行加工整理后，生成商品的模板，这里生成的模板都是经过运营调整审核合规的，能直接拿给所有商家去建品。
• 商品主业务，建品的环节，商品建品可以是标库建品，也可以是商家自定义建品，这里涉及到了组装商品的各个维度的属性，比如、图片、长、宽、高、重量、产地、等等。
• 图片的话我们也会拉取图库的模板进行套用。
• 商品创建完成后，运营开始审核，通过标库模板创建的商品是可以免审的，商家自主创建的才会审核。为了提升商品的质量，比如图片像素、属性规格等等，建好的品还会经过商品的治理，检测出不符合要求的商品呢，回炉整改，经过层层筛选，最终商品才会上架售卖。

1、那在这个过程里，我们先明确业务模块面向的角色是谁？也就是Who

这里的角色不一定非得是人，也可以是系统，代表一个身份。比如拓品面向的角色就是商家、运营、标库系统。标库面向的角色是运营、商品系统、商家。

2、确定好了角色，紧接着弄清并且评估每一个业务模块的特点、价值？也就是Why。

是否有必要单独领出业务来划分。比如拓品，价值是协助商家拓展更多的品类到线上。标库系统，提供的商品模板能够协助商家一键建品，极大的缩短了标准品的建品时间，提高了商家的建品效率，模板免审的特征可以大大节约运营的审核时间。商品主业务模块，是所有商品业务的汇聚中心。图库业务，同标库一样，提供现成的图片供商家选择，提高商品的图片质量。

3、明确了各个业务模块的价值后，每一个业务领域的功能如何设计让业务价值最大化，这里对应What。

也就是怎么设计业务内部的闭环逻辑。比如拓品，我们如何设计拓品数据的分析规则，如设计页面交互。

4、然后是How如何实现这些方法的具体逻辑。

5、再就是Where，也就是业务模块间的边界交互。对应了业务的界限界限上下文。

通过6W领域场景分析，我们提炼了商品的每个业务模块的特点和价值。那这些模块如何进行交互？又是如何面向对象去建模呢？

商品内部所有的业务目的只有一个，就是让商品以最完美的姿态展示在app上售卖，让用户看到下单购买，我们就以这条上架售卖诉求为主线，采用四色建模的方式对商品进行建模。

我们把商家操作商品上架的过程先梳理出来

第一步 商家通过标库模板一键生成商品或者通过第三方中台系统对接的方式把商品录入至到家商品系统。

第二步 运营进行商品审核

第三步 审核商品

第四步 维护商品属性、价格、库存、促销

第五步 商家维度上架、门店维度操作可售

到家的运营需要对商家的商品进行审核，审核不通过则驳回、督促商家整改治理，审核通过后，商家对商品进行库存、价格、活动维护，满足一系列要求后，商品上架售卖。

试想一下，商家辛辛苦苦创建好了商品，然后又经过那么多个环节让商品在APP上显示售卖，但是最后发现，商品在APP上不展示。

商家让你去帮他们排查问题

• 这时候你第一时间可能会想到这个商品是否存在，也就是是否创建成功了？
• 是不是被审核拦截了？
• 接着会看下商家商品是不是下架状态？
• 门店商品是不是非可售？
• 然后看下商品是否已经维护了一个门店价格？

你会发现我们对整个流程的追溯都是通过对数据的追溯来完成的，我们把每一个阶段发生的事情记录串联起来，就会清晰的发现问题所在，这也是我们业务系统的主要目的之一，每一个业务，每一个环节，每一个链条都是可追溯的，面向的是业务的顶端，也就是使用者的最真实的需求。

四色建模

接下来，我们开始使用四色建模的方式对商品系统进行建模的实践。

第一步

首先识别出有时标性的对象，这类对象的特点之一是可追溯，有时效性。比如标库模板同步记录，可以通过这个对象追溯标库录入商品的过程，我们把这些有时标性的对象提取出来进行整理，按照关系构建成核心骨架，这类对象用粉红色填充。

第二步

梳理好了时标性骨干图后，我们开始为骨干补充实体对象，一般的实体对象主要有三种，人、地点、物，比如图里的，治理的基础数据，对应多个治理结果，，标库模板数据又对应多个商家商品，同时1对1对应标库模板创建同步，商家的商品1对1对应商品建品录入，还有商家对应对多个门店，门店又对应多个门店商品库存，和门店商品价格，这类实体对象用谈绿色填充。

第三步

我们对这些实体对象进行抽象，以角色的身份参与到业务的流程中去。比如标库数据抽象出标库模板进行同步，商品治理抽象出治理规则的角色进行商品治理。这类对象用淡黄色填充。

第四步

添加描述信息这类对象用谈蓝色填充

通过四色建模的流程呢，我们可以梳理出以商品上架售卖为主线的各个业务模块之间的交互和关联关系

同时呢每一个模块内部同样也是可以用四色建模的方式来划分业务领域的子域。从而进行子域的建模和划分。上述就是围绕商品最终上架售卖的核心诉求进行的四色建模的全过程和传统的建模进行一个比较，会发现有很大的不同，传统的建模是以数据库为领域，通过表结构自下而上的去进行业务流程的推导，而领域建模则是从业务使用方的诉求点出发，自上而下的去推导业务如何进行，很显然，后者比较合理一些。

总结

我们采用四色建模面向对象的去划分业务领域，配合领域场景分析，我们可以确定哪些业务环节点可以进行独立的微服务部署，从而达到划分业务界限、解耦业务、独立部署业务微服务的目的。

配合建模，我们对商品业务领域进行划分，针对这些业务独立部署了微服务。

• 商品治理系统，负责规范、治理商品基础信息，商品中台，负责到家商品同第三方商品系统的对接。
• 商品属性服务，维护了商品的分类属性，特殊属性信息。
• 商品图库，维护了大量的标准图片模板，提升商品图片的质量。
• 商品限购，提供了商品限购业务的活动配置，方便商家和运营对商品设置不同的限购规则。
• 商品标库，提供了商品建品的模板，提升建品的效率。
• 商品拓品，利用数据分析协助商家拓展品类。

每个微服务都通过MQ\API\RPC同商品主服务进行适配，从而形成一个商品微服务的体系。

建模的目的在于更好的理解业务之间的关系模型，确定业务的界限上下文，避免业务的耦合。

随着新的业务的不断增加，我们需要不断的去更新 、完善我们原有的模型，就和我们系统构建可演进的架构一样，我们也需要构建一套可演进的系统业务模型，在新业务加入的时候，及时的发现业务模块间矛盾冲突，利用建模的方式来分析、解耦业务，引导我们更好的搭建业务系统架构。

• 我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。