写点什么
  • 发布
  • 评论
  • 划线
  • 收藏
  • 关注
  • 全部分类
DDD实战(3):从需求到代码实现生鲜电商系统
DDD 实战 (3):从需求到代码实现生鲜电商系统

DDD 本质上是个“软件设计”方法论,在正式开始“群买菜”的软件设计之前,我们先对 DDD 整体方法论做一个简单的、从我个人角度理解的介绍。本篇在对 DDD 整体工作框架做了个简要的介绍后,我会在本篇中完成 DDD 工作框架中的第一步——“群买菜”系统的全局分析。

DDD实战(2):从需求到代码实现生鲜电商系统
DDD 实战 (2):从需求到代码实现生鲜电商系统

真正开始 DDD 旅程前,我想让您看到经过 DDD 设计之后的代码长啥样。我想,这是所有本着“talking is easy, show me your code”理念的程序员都比较在乎的观念。

DDD实战(1):从需求到代码实现生鲜电商系统
DDD 实战 (1):从需求到代码实现生鲜电商系统

通过本专题的旅程,您将能够理解 DDD 从需求分析、到架构设计、到编码实现的整个过程,以及其中的工作方法和实用技巧。并将得到一份按照 DDD 了理念设计的、完全开源的生鲜电商小程序系统源代码供参考。

个人成就
  • 发布了 3 篇内容

    22436字, 被阅读 445

  • 获得了 8 次赞同

    获得了 6次喜欢, 获得了 2 次收藏

  • 参与了 7 次互动

    互动包含发布评论、点赞评论、参与投票等

TA 关注的
还没有关注其他内容哦
最新评论
  • 壮士断臂我觉得“上下文”的界定,主要是为了保持模型的一致性,而不是考虑“领域服务”有没有地方放等因素,所以很期待,在这个电商系统里,会有哪些模型,并且是怎么建模的

    DDD 实战:从需求到代码实现生鲜电商系统 (2)

  • 深清秋我的观点是不可以,因为至少要考虑如下因素(以 order 上下文为例): 1. 订单相关的“领域服务”就没地方放。比如:订单创建时需要从商品上下文获取商品快照信息,这不是“订单”聚合该有的行为(聚合根其实也是实体对象,而实体对象不允许访问南向网关的端口资源的)。 2. 当然,你也可以说,这些“领域服务”就放在“电商上下文”中。但这个粒度太粗了,如果整个电商系统是个上下文,其实战略设计就没有意义了。同时,“限界上下文”划分是微服务切分的最关键的依据之一,如果整个“电商系统”是一个“限界上下文”,那就相当于真个“电商系统”只能是一个微服务。大部分情况下,不会允许一个“限界上下文”切分为多个微服务的,因为那样会造成微服务之间的耦合太强了,基本上“微服务”之间的反复来回调用会非常多(我们在生产系统中就出现这种情况,某个前端请求的单个接口编码过来后,到后台某个“微服务”中心反反复复调用了 16 个服务接口之多),因为一旦这种“不清晰”的“微服务”切分实现出来后,程序员就没法控制它们相互之间的耦合性了。

    DDD 实战:从需求到代码实现生鲜电商系统 (2)

  • 壮士断臂如果把电商系统划定为一个 context,而 customer、merchant、order 和 shop 等都视为聚合, 好像也不是不可以?

    DDD 实战:从需求到代码实现生鲜电商系统 (2)

  • 深清秋明白你的意思。你是不是觉得“订单”、“客户”只是一些具体的实体类对象?其实不是的,“订单”上下文里面还有“订单行”、“商品快照”等等实体对象,已经“价格”等值对象。所以“订单”是上下文,不是实体类、也不仅仅是聚合根,至少还会包含一些“领域服务”的,所以它必须是个“订单上下文”。

    DDD 实战:从需求到代码实现生鲜电商系统 (2)

  • 壮士断臂valueadded 下的上下文,好像是按模块划分边界,这样划分会不会得有点细

    DDD 实战:从需求到代码实现生鲜电商系统 (2)

深清秋