深清秋

壮士断臂我觉得“上下文”的界定，主要是为了保持模型的一致性，而不是考虑“领域服务”有没有地方放等因素，所以很期待，在这个电商系统里，会有哪些模型，并且是怎么建模的
 DDD 实战：从需求到代码实现生鲜电商系统 (2)
深清秋我的观点是不可以，因为至少要考虑如下因素（以 order 上下文为例）： 1. 订单相关的“领域服务”就没地方放。比如：订单创建时需要从商品上下文获取商品快照信息，这不是“订单”聚合该有的行为（聚合根其实也是实体对象，而实体对象不允许访问南向网关的端口资源的）。 2. 当然，你也可以说，这些“领域服务”就放在“电商上下文”中。但这个粒度太粗了，如果整个电商系统是个上下文，其实战略设计就没有意义了。同时，“限界上下文”划分是微服务切分的最关键的依据之一，如果整个“电商系统”是一个“限界上下文”，那就相当于真个“电商系统”只能是一个微服务。大部分情况下，不会允许一个“限界上下文”切分为多个微服务的，因为那样会造成微服务之间的耦合太强了，基本上“微服务”之间的反复来回调用会非常多（我们在生产系统中就出现这种情况，某个前端请求的单个接口编码过来后，到后台某个“微服务”中心反反复复调用了 16 个服务接口之多），因为一旦这种“不清晰”的“微服务”切分实现出来后，程序员就没法控制它们相互之间的耦合性了。
 DDD 实战：从需求到代码实现生鲜电商系统 (2)
壮士断臂如果把电商系统划定为一个 context，而 customer、merchant、order 和 shop 等都视为聚合，好像也不是不可以？
 DDD 实战：从需求到代码实现生鲜电商系统 (2)
深清秋明白你的意思。你是不是觉得“订单”、“客户”只是一些具体的实体类对象？其实不是的，“订单”上下文里面还有“订单行”、“商品快照”等等实体对象，已经“价格”等值对象。所以“订单”是上下文，不是实体类、也不仅仅是聚合根，至少还会包含一些“领域服务”的，所以它必须是个“订单上下文”。
 DDD 实战：从需求到代码实现生鲜电商系统 (2)
壮士断臂valueadded 下的上下文，好像是按模块划分边界，这样划分会不会得有点细
 DDD 实战：从需求到代码实现生鲜电商系统 (2)

创作场景

深清秋

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

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

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

个人成就

TA 关注的

最新评论