加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

领域驱动设计之聚合与聚合根实例一(订单)

发布时间:2020-12-14 02:01:33 所属栏目:百科 来源:网络整理
导读:领域驱动设计之聚合与聚合根实例一 通过一个实例来说明如何划分聚合与聚合根 场景:一个下订单的业务,一个订单必须有相应的客户信息,订单下有订单项,每个订单项必须有相应的产品信息,产品有分类的信息。 1.根据这个基本的需求,我们初步确定的实体、值对

领域驱动设计之聚合与聚合根实例一

通过一个实例来说明如何划分聚合与聚合根

场景:一个下订单的业务,一个订单必须有相应的客户信息,订单下有订单项,每个订单项必须有相应的产品信息,产品有分类的信息。

1.根据这个基本的需求,我们初步确定的实体、值对象与关联关系为(这里采用EF的Model First):

2.经过业务深入分析,以及聚合与聚合根确定原则,最终我们确定的聚合与聚合根是(红色代表聚合根,蓝色代表聚合内的实体,灰色代表值对象):

划分与确定理由
1.订单、客户与产品都可以在不同的领域被独立访问到,所以应该是属于不同聚合的聚合根。

2.订单初看好像要依赖于客户才能存在,其实不然,一是订单的生命周期与客户的生命周期不是一致的,二是订单与客户之间也没有不变的一致性规则。

3.订单只需要下订单那个时刻客户的姓名、电话与地址等相关信息,所以作了一个值对象保存那个时刻的客户相关信息,因可能业务上需要通过订单查询客户当前的信息,所以做了一个客户ID关联到客户对象。

4.订单项也只需要那个时刻的产品的名称、单价等信息,所以作了一个值对象保存那个时刻的产品相关信息,因可能业务上需要通过订单项查询产品当前的信息,所以作了一个产品ID关联到产品对象。

5.产品初看好像要依赖于产品类别,实际上产品类别只是对产品的一种划分,所以产品类别做成值对象,如果业务上要对某个产品类别进行促销等业务逻辑,则产品类别应该划为一个单独聚合的聚合根。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读