为什么要建模
- 建模本质上是一种抽象。抽象就是归类,其目的是减轻认知的负担,避免重复的思考和工作,提升人的计算能力。所以,「通用」是建模的第一步,接下来我们还需要「复用」建好的模型
- 为什么要建模
- 要把日常生活中的业务模型提取出来,显性化,让不同的人对业务的理解达成一致
- 要归类复用,避免重复的工作,让人可以关乎更高层面的事务
怎么建模才合理
- 判断模型好坏的重要依据是它的使用效率(拓展度,灵活度,与组织的对应度)
- DDD分层
- UI 层,负责界面展示
- 应用层,负责业务流程
- 领域层,负责领域逻辑
- 基建层,负责提供基建
- 分层依据是:越往上,预期变动越频繁;越往下,预期变动越少
领域模型具体指什么
按DDD的定义,领域模型应该捕捉"业务规则"或者"领域逻辑",而应用模型则捕捉"应用逻辑"
模型属于哪一层,有个粗略的判断方式。如果是一个实体和针对实体的增删改查,就属于领域层,如果是一个场景,比如出现在UI菜单上的选项,就属于应用层
- 比如:账单,用户,编辑商品,编辑库存,这些是领域层;购买商品则是应用层
- 前者是针对实体的操作。每一个实体都只有增删改查这样的操作。与之相反的是,要完整实现「购买商品」这个场景,业务需要检查库存,创建订单,创建交易等多个操作。
- 这样看来,领域模型就像是数据库的表,不过,除了字段定义之外,领域模型还需要有领域逻辑。关系型数据库通常可以部分实现领域逻辑,比如使用外键,自增ID等等,但是更为复杂的领域逻辑则需要用代码来实现。比如,在创建订单的时候,需要扣除相应数量的库存;当订单失效,则需要恢复库存。
- 理解领域逻辑
- 领域逻辑就是显性的专业知识,是相对容易理解和学习的部分(符合逻辑推理的)
- 领域逻辑是「提纯,通用」的「规则」。
- 只管"合规",但不管"合理",例如:下架所有商品,是否合理？这不属于领域模型关心的范围,这些是放到应用层去做
模式的设计和实现
- DDD的模型既属于业务描述又属于代码,数据库定义
- 设计和实现的最佳契合点在界面之中。这里的界面可能是一个类的公开成员函数,也可能是一个微服务上暴露出来的Restful接口,或者是一个公开的普通Web API。所以建好的模型和暴露出来的界面,接口应该有「相当高(或者完全一致)的对应关系」
总结
- DDD把业务分成UI,应用,领域,基建四层,其核心是「高度提纯,通用,少变化」的领域层,是所谓的领域驱动
- 领域层中包含领域模型,捕捉领域逻辑,暴露出接口用于操作领域模型,这些接口提供的操作可以确保领域是自洽的
- 领域模型既是业务描述,又是代码实现的结构设计,两者的结合点在于公开出来的界面,接口
