【实战示例】领域建模

目录

1.前言

2.如何识别出子领域

3.商品子领域

4.商家子领域

5.物流子领域

6.支付子领域

7.订单子领域

8.顾客子领域

9.售后子领域

1.前言

前面我们聊了什么是面向对象？如何进行面向对象的需求建模。在上一篇的需求建模里面，用用例描述清楚了各个场景，并辅以流程图将各个用例串联了起来，完整的描述好了整个系统：

【实战示例】面向对象的需求建模-CSDN博客

接下来就是进行领域建模，即设计好实体类、建立好类之间的关系。领域建模分为两步：

• 识别出子领域

• 设计出每个子领域中的类关系

2.如何识别出子领域

如何识别出子领域是领域建模里首先要做的一个重点，很多DDD的教程长篇大论一谈到如何划分子领域就很含糊，一般都会说“凭经验”，这就有点耍赖了，其实划分子领域的时候确实是需要经验丰富的人来牵头，也需要大家一起讨论，毕竟一个人的思维确实是会有局限性的，但是划分子领域的具体打法还是有可以总结的具象化的打法的：

• 系统的参与者肯定各自是子领域：顾客子领域、商家子领域、管理员子领域

• 所有参与者共用到、共同参与的东西也是子领域：订单子领域、商品子领域、支付子领域、售后子领域

本系统中物流的管理不介入系统，而是由第三方负责，如果物流管理要接入系统，物流也是多方要参与的一块东西，它也是一个子领域。

识别出子领域后再思考一下，有没有子领域是完全没有实体的？

有！管理员子领域其实就只有审核工作，没有任何实体，用的实体都是其它子领域的，所以没有实体的子领域不用独立出来讨论，去掉管理员子领域，于是本系统的子领域划分如图：

3.商品子领域

回忆一下，UML中的组合关系箭头：

在领域建模的时候有关联的概念之间最好采用组合关系，因为组合关系的其实是一条链路，如果改动链路上的一环能传递影响到其它环节，比如禁用商品，就会沿着组合关系的连线影响到沿路上的所有节点，onsale会随之禁止 比如禁用商户，就会沿着组合关系的连线影响到沿路上的所有节点，导致商品被禁止、onsale被禁。

该子领域的核心概念是——商品，商品关联运费模板、关联分类、关联销售信息、关联优惠活动、关联草稿、关联店铺。需要注意的是价格并不作为商品的属性，而是抽出来作为销售信息，因为商品随着一些外部原因进货价会不同，销售价也会变化，查看商品的历史售价又是常用的功能，所以抽出来单独作为一个实体。

4.商家子领域

该子领域的核心概念是——运费，为什么不是商品？因为商品作为一个独立的子领域已经描述过了，所以落到商家子领域这里还需要描述的核心概念就剩如何设置运费模板。运费有很种收法，根据对需求的细化确定为按件数算、按重量算、按体积算、按金额算四种方式。还有就是不同地区的收费方式可能不同，所以建模如下：

5.物流子领域

由于物流是交给第三方的快递公司，如顺丰、圆通、中通等，所以物流的详细管理并不在本系统中，本系统中只需要录入一个快递和订单之间的关系，也就是物流单，方便用户查询到自己下单的东西的物流进度。物流信息这一块从第三方物流公司提供的API来取。所以物流子领域的建模很简单：

6.支付子领域

支付子领域是顾客、商家、平台三方都要用到的一个公共部分，所以抽成一个子领域，围绕整个支付、分成、退款等建立好类关系。

具体建模关系如下：

该子领域的核心实体——支付交易。

每一次交易会产生一次商铺和平台之间的分账，所以支付交易实体要关联分账记录，具体的分账比例来自于商品的分账比列属性。一次交易产生两个分账记录，一个是给商铺的分账，一个是给平台的分账。

当订单被取消会出发交易被取消，从而产生退款交易记录，退款交易记录需要关联退分账记录，退分账记录分为两个一个是商铺的退分账记录，另一个是平台的退分账记录。

7.订单子领域

订单项里面会记录这个商品下单时的价格是多少。在支付子领域里面已经说过了，订单取消会发起支付交易和退款交易，所以订单还要关联支付交易、退款交易。

8.顾客子领域

商品和订单都在各自独立的子领域说过后，剩给客户子领域还需要独立表述的就只剩购物车了：

9.售后子领域

售后分为退货和换货，退货和换货需要的逻辑不同，所关联的实体也不同，所以当出现这种分叉的，需要进行选择的情况时，我们把逻辑表述为一个黑盒子Service即可，在后续的设计阶段再展开详述各个过程。