关键词：
商品建模之路
最近在做电商业务中，有关商品业务改版的一些东西，后端的架构设计采用现在很流行的微服务，有关微服务的简单概念：
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
关于改版的业务设计，还是想尝试 DDD 领域驱动设计，之前写的一些相关文章，都是直接进行战术设计，而非在战略设计基础上进行，所以最后可能会出现一些问题，所以这次的过程是：边了解业务、边了解 IDDD 书中关于战略设计的部分，然后尝试使用战略设计的方式进行业务分析，最后再细分出具体的战术设计，没有正确的设计方案，只有合适的设计方案，排除技术之外的业务分析过程，还是蛮有意思的。
DDD 战略建模（包含概念）：领域（Domain）、核心域、子域、界限上下文（Bounded Context）、上下文映射图（Context Mapping）。
相关文章：
1. 业务流程
业务场景：发布商品
业务场景就上面四个字，看起来很简单，但其实具体分析起来，所包含的东西还是蛮多的，整个发布商品过程，就像一个商品诞生的生命周期一样，需要经历各个阶段和过程，直到商品正式发布出来，并且在这个过程中，有一系列的其他概念由商品衍生出来，比如库存、分类、品牌等等，还会有一些用户的行为参与，比如小二的后台审核等。
在业务分析过程中，我还是比较喜欢画一张简单的业务流程图，并不一定很规范，你也可以直接手绘出来，从业务流程图中，我们可以看到整个的业务方向，有利于我们从中找出关键的业务点，并进行具体分析设计。
发布商品业务流程图：
图比较简单，我们需要从添加商品到发布商品完成的过程中，抽离出关键的业务点，并且这些业务点事需要在业务系统中进行设计的，发布商品流程大概分为两个部分：
- 商户发布商品：这部分内容比较多，先选择分类（分类需要进行设计），然后填写基本信息（根据实际的业务，有很多不同的设计，是发布商品的核心，需要重点考虑），填写完成之后（两种选择：保存草稿和发布），在小二审核之前，需要填写入库单，用来更新商品库存，然后进入小二审核阶段，如果审核成功，并且商户选择商品上架，则代表着整个商品发布的业务流程跑完了。
- 小二审核商品：小二根据一些规定进行审核商户发布的商品，这个部分人工因素很大，但发布商品的规定一般是确定，因为是人工进行操作，所以这部分内容在业务系统设计方面体现不大。
其实，选择分类可以归纳到填写基本信息中，重要的是基本信息具体是什么？这部分包含的业务是什么？该如何设计呢？后来分析了下，除了一些商品的基本信息之外（比如标题、价格、商品详情、商品图片），还包含了品牌、分类、属性（一般指的是 sku）等，像标题和价格之类的属性一般是具体的值，后面我们在战术设计的时候，直接把它们设计成值对象即可，但对于品牌、分类之类的对象，需要进行单独进行设计，因为它们不是一个值所能代表的，需要进行独立维护。
除了商品信息之外，后面就是填写采购单用来更新商品库存了，这部分业务内容有点像外部服务一样，通过外部服务的一些操作，最后的结果导向商品模型，这部分类似的业务以后可能会很多，比如小二审核商品信息，也像一个外部服务一样，不过是人为进行操作的，审核最后的结果导向商品状态，我们可以归纳出，可以改变商品状态的一些行为，都是需要进行考虑的业务，并且这部分业务在后面建模的时候，需要重点设计。
画业务流程图的目的，在于熟悉整个业务的大致流程，以及对商品生命周期的了解，但只是大致的表述，当你对业务理解越深的时候，业务流程图也就会越复杂，但基本的框架是不变的，所以，在画的业务流程图的时候，要找出业务的不变规则，比如发布商品肯定要填写信息、然后小二审核等，变的业务都是在这些不变的规则之上丰富起来的，最后形成整个健全的业务系统。
2. 限界上下文
关于领域、核心域和子域的概念，相对比较容易理解，领域就是业务系统的全部，核心域就是业务系统最重要的部分，比如商品业务系统，核心域就是商品，其他相对不重要的业务部分就是子域，子域又分为支撑子域和通用子域，支撑子域用来支撑核心域，在整个领域中，可以被公用的子域，称为通用子域。
限界上下文是一个显式的边界，领域模型存在这个边界职位，领域模型把通用语言表达成软件模型，一般在设计的时候，会把领域和限界上下文一一对应（但也不是相对的），有时候限界上下文很大，但有时候限界上下文也很小，比如一段业务描述也可以称之为限界上下文，不管概念是怎么定义的，只需要知道限界上下文的核心是边界，边界的目的就是内聚合隔离。
一张简单的商品限界上下文图（虚线表示领域的边界）：
首先，在商品领域中，商品是核心域，并对应一个商品上下文，库存被设计为一个通用子域，因为以后交易的业务场景会被用到，并对应一个库存上下文，品牌通用子域也一样，业务场景可能会对品牌的单独处理（比如品牌街，这是和商品不想关的），所以设计成通用子域会相对好些，分类支撑子域和属性子域相对复杂点，其实这里的分类和属性都是相对于商品而言的，你可以成为商品分类和商品属性，独立于商品之外，分类和属性是没有任何存在的业务意义的，所以，把它们设计为商品领域的支撑子域会比较好些。
另外，关于分类上下文和属性上下文之间的关系，从上面图中就可以看到，在业务场景中属性依附于分类，比如在发布商品页面，填写商品属性之前需要先确定商品分类，因为不同的分类有对应不同的属性，比如表带材质属性，只有手表分类下才会有，其实它们也可以直接合二为一，叫做分类属性支撑子域，对应分类属性上下文，上面说过添加属性之前，必须先确定分类，属性就像是分类中的一个子域，属性其实和商品没有直接的关系，它和商品的所有关系，必须都通过分类，并且属性的数据维护也是如此，这个后面会有调整，再详细说明。
分类在具体的实现中，会相对比较简单，有点像品牌的实现，顶多和商品有一些关联，但属性实现相对比较复杂些，因为属性项和属性值都是动态的，并且属性的展现形式也是动态的，比如一个属性项可能对应多个属性值，并且展现可能是组合形式的（文本+单选+下拉列表），这方便在也体现在数据存储的时候，不过可以按照一定的格式用 json 进行存储，展现方式也是一样。
限界上下文就像一个手术刀，将领域一点一点的进行解剖，解剖出来的部位独立进行实现，限界上下文的具体实现就是战术设计，并且各个限界上下文的实现之间是相互不影响。
3. 数据模型（聚合和实体）
限界上下文让我们明白，我们到底需要做什么东西，接下来就是针对这些东西的具体设计和实现了，怎么实现？就是战术设计。
战术建模（包含概念）：聚合（Aggregate）、实体（Entity）、值对象（Value Objects）、资源库（Repository）、领域服务（Domain Services）、领域事件（Domain Events）、模块（Modules）。
关于战术设计的首要前提是聚合，后面实体和值对象等概念，都是在聚合的基础上衍生出来的，关于聚合的概念就不多说了，但需要说明下聚合设计的注意点：
- 尽量小聚合设计：有助于减少事务的提交冲突，也有利于系统性能和可伸缩性，但不能过小，比如一个聚合只包含唯一标识和单个属性，这种设计不合理。
- 根实体可以作为聚合根。
- 聚合边界和真实的业务约束是一致的。
- 通过唯一标识引用其他聚合。
- 事务一致性：在一个事务中，只能修改一个聚合实例。
- 在聚合之外使用最终一致性：如果可以不在意延迟，一般用领域事件进行实现。
先简单看下商品所包含的东西：
图中主要说明的是商品大致包含的内容：分类、属性和基本信息，属性又有具体的分类，但都基于分类确定的情况下。
一张简单的商品数据模型图：
简单归纳下：
- 商品（聚合根）：商品（根实体）、商品图片（实体）、商品 sku（实体）、商品描述（实体）、商品调整纪录（实体）
- 库存（聚合根）：库存（根实体）、入库详情（实体）
- 品牌（聚合根）：品牌（根实体）
- 分类（聚合根）：分类（根实体）、分类属性（实体）、分类属性值（实体）
实体中的属性只是一些示例，并不详细，值对象并没有在图中体现，因为实体的属性都可以被设计为值对象，这部分在具体实现的时候，再详细进行考虑，聚合根和实体、聚合根和聚合根之间的关系用箭头进行表示了。
关于分类和属性，在限界上下文设计的时候，被分开设计了，但后来想了一下，还是设计成一个比较好，分类作为聚合根，分类属性和分类属性值作为衍生出来的实体。
关于数据模型图，就不详细说明了，内容都在上面的图中，况且现在还不是很完善，后面可能还会进行调整。
大概就纪录这些。
双11专栏|基于神经渲染的商品三维建模技术
...以规模化的针对消费者的个性化需求进行满足，实现商品放我家的效果。看商品不再是看图片、看视频，而是可以把指定商品放到自己家的真实户型中进行展示，AI设计根据指定商品和真实户型进行全屋搭配设计，... 查看详情
商品3d建模的视觉定位和前景分割方法
...经渲染的3D建模产品objectdrawer，用户只需要环拍一圈商品的视频，就可以生成3D模型。在物体重建算法流程中，需要先计算出每一帧图像的相机位姿（平移和旋转）。之后需要对图像中前/背景进行像素级的分割... 查看详情
如何为数据库中的项目建模折扣？
...在建立一个电子商务网站，并希望在有限的时间内为某些商品提供折扣。我的产品表（MySQL）如下所示：产品-产品编号-姓名-重量-价格（商品封面上的价格）我是否应该为交易制作另一张桌子：交易-交易ID-productID（外键）-折扣... 查看详情
用户多兴趣建模mind
...和排序阶段。在召回阶段，根据用户的兴趣从海量的商品中去检索出用户（User）可能感兴趣的候选商品（Item），满足推荐相关性和多样性需求。在排序阶段，根据不同的目标，如CTR， 查看详情
画像分析-概述
...根据需要，对已有的多源数据分类为实体（卖家、买家、商品）和实体关系（商品销售交易） & 查看详情
数据建模——实体#yyds干货盘点#(代码片段)
...个事实（Facts），它包含了这个订单的信息，例如购买的商品、购买的数量、订单时间、支付方式等内容。其中，购买的商品可以作为一个维度（Dimensions），可以有不同的级别，例如类别、品牌、型号等。这个维度可以帮助用户... 查看详情
2021年mathorcup高校数学建模挑战赛a二手车估价问题数学建模(代码片段)
...环节的流通需求越来越大。二手车作为一种特殊的“电商商品”，因为其“一车一况”的特性比一般电商商品的交易要复杂得多，究其原因是二手车价格难于准确估计和设定，不但受到车 查看详情
用户多兴趣建模mind
...和排序阶段。在召回阶段，根据用户的兴趣从海量的商品中去检索出用户（User）可能感兴趣的候选商品（Item），满足推荐相关性和多样性需求。在排序阶段，根据不同的目标，如CTR，CVR，... 查看详情
订单/发票/付款数据库建模
...在设计一个具有以下场景的电子商务网站：客户可以购买商品并创建订单。订单可能有未知费用，将在客户之后添加支付项目的总金额。也就是说，客户支付先一定数量。该订单增加了一些费用并更改了总额。客户再次支付差价... 查看详情
电商促销优惠规则业务分析建模
...。优惠类型，对于电商网站主要是下面4类：金额赠品：商品、优惠券、 查看详情
3d试衣sdk全面开放
...己的商城，小程序，h5，Web，门店系统等3产品建模：真实商品进行建模，1:1还原商品4、个性化需求定制：可对商品建模使用自有模特或者普通模特需求进行选择，已达到产品的最佳展示状态5一键生成：正、侧、后图片，生成展... 查看详情
数据仓库，数据集市建模
...中提取三个维度：时间维度(昨天早上)，地点维度(京东),商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。 &n 查看详情
用户画像
...击，购买，签收，评价，退货等—比较重要的行为：购买商品，浏览商品，放入购物车，关注商品等根据行为可以得出标签：潮妈族，纠结商品，最大消费，退货数量，败家指数，品牌偏好，用户活跃度等确定标签与根据算法猜... 查看详情
基于多因素的搭配推荐模型
...的搭配推荐模型，如之前的博客 基于图像信息的搭配商品推荐 中所述，可以看做是基于单因素对搭配进行建模，即认为搭配的商品应该在单因素--风格上相似，然后在对商品映射后的latentspace即风格空间中，搭配的商品... 查看详情
[数学建模模拟退火法与旅行商问题]
...问题。它的描述是这样的：一名商人要到若干城市去推销商品，已知城市个数和各城市间的路程（或旅费），要求找到一条从城市1出发，经过所有城市且每个城市只能访问一次，最后回到城市1的路 查看详情
elasticsearch数据建模实战指南
...管理1000 家连锁门店，如何更高效地查询自己管辖的商品类目？企微一个人维护了1000个员工，如何快速查询自己管辖的员工信息&#x 查看详情
2021年mathorcup高校数学建模挑战赛——大数据竞赛a题
...环节的流通需求越来越大。二手车作为一种特殊的“电商商品”，因为其“一车一况”的特性比一般电商商品的交易要复杂得多，究其原因是二手车价格难于准确估计和设定，不但受到车本身基础配置，如品牌、... 查看详情
高级数据库设计与应用05-xml数据库建模(代码片段)
...大部分。其中，前台购物系统包括会员注册、会员登录、商品展示、商品搜索、购物车、产生订单和会员资料修改等等功能。后台管理系统包括管理用户、维护商品库、处理订单、维护会员信息和其他管理功能。根据系统功能描... 查看详情