领域, 子域和限界上下文

前言

关于领域设计, 我也是初学者, 下方的诸多言论只是我个人理解想法, 并不一定是正确的.

限界上下文

限界上下文 是从复杂系统中划分模块的方法, 限界上下文的命名最好使用偏动词的方式, 这样方便开发者跳出数据库建模的架构影响.

在使用DDD思想的时候, 最好先抛弃框架, 数据库等等的约束, 先把设计做好, 最后在来考虑框架,

子域

限界上下文和 子域 最好保持一对一的关系,

电商系统 的模块划分

按照我之前的想法, 根据经验和直接我会把电商系统划分成:

1. 用户模块
2. 商品模块
3. 订单模块
4. 支付模块
5. 库存模块
6. 物流模块
7. 评价模块
8. 搜索模块
9. 商家模块

这也是很多人的直觉划分, 但是上面的划分是很有歧义的. 比如用户模块:

“用户” 的定义是啥?

1. 如果一个顾客在搜索的时候, 需要用户用户的标签兴趣爱好等信息, 那么用户模块中的用户是否需要包含用户的标签, 兴趣爱好等数据呢?
2. 如果一个用户在下单的时候, 需要用到用户的收货地址 和 银行卡信息, 用户模块中的用户是否需要包含 收货地址 和 银行卡信息?
3. 用户在上架商品的时候, 需要判断用户是否商家角色, 是否有权限等, 用户模块中的用户是否需要包含权限信息?

可以看到随着模块的增多, 和用户模块的关联也增多, 用户模块需要包含的信息也增多, 用户模块完全和各个模块强耦合, 一个用户中包含太多各个模块独有的信息了; 这说明简单的划分用户模块是一种不好的划分方式.

DDD中是如何划分电商系统的上下文

我们简单的把模块划分类比成限界上下文, 上下文以偏动词划分, 我个人理解的划分方式如下:

我也是初学, 这图只是我自己的理解. 其实 用户 这个名词在不同的上下文中是有不同含义的, 我们无法抽出一个符合所有模块要求的用户 那么就说明用户模块的划分是有问题的.

比如一件货品.

• 在购买上下文中, 可能表示的是商品, 更关注的是货品的价格, 规格等
• 在库存上下文中. 价格这个属性根本不重要, 库存更关注的是数量和体积等
• 在物流上下文中, 这个货品的价格和数量都不关系, 值关系体积和重量
  同样一个货品 在不同上下文中 关注的侧重点不同, 自然不能提取出一个通用 货品模块了, 上面的用户模块也是一样的原理.

上图中 发货 这个动作在价格模块中都包含, 但是注意他们是不同的, 上下文就相当于语境, 同样动作在不同语境中是根本不同的.

图中的所有上下文命名都是动词的方式, 把相关的一系列操作合并到一起成一个上下文, 划分出了上下文, 一个系统的模块大概率也差不多划分清楚了, 接下来就是详细的代码结构的设计了