《领域驱动模型》实在太理论了，所以我找了另一本《解构领域驱动模型》。
领域驱动设计不足
- 缺乏规范的统一过程
- 缺乏与之匹配的需求分析方法
- 缺乏具有指导意义的架构体系
- 缺乏固化的指导方法
领域关键点
分层：合理、清晰的封层结构，确定了边界领域概念
统一语言
统一的领域术语，减少沟通成本，不仅要提供中文的，还要有英文的
领域
核心子领域
是目标系统的核心，是核心问题。子领域的划分背后是分而治之的思想体现，这是控制问题复杂度的一种手段。子领域的划分可以通过功能、业务进行划分。
通用子领域
支撑子领域
次要问题，往往是为核心子领域的功能提供支撑，例如物流系统中的地图功能就是支撑子领域
限界上下文
业务级别。限界上下文封装了领域知识，提供了业务能力，能执行活动，扮演不同角色，相对完整的业务能力这是限界上下文的定义。
设计限界上下文时需要注意4个要素：最小完备，自我履行，稳定空间，独立进化。
它是业务能力的纵向切分，它维护着业务的边界，它是自治的架构单元。
限界上下文和模块有点类似，模块可能需要依赖其它模块的支撑才能提供完整能力，而限界上下文本身就能提供一个完整自治的业务能力。
限界上下文是领域驱动设计中最重要、最基本的架构设计单元。
案例
书中列举了电商中商品的案例，Product 在采购，订单、物流都会用到，但是各个业务模块用到的字段不一样，采购需要进价等，物流只需要需要商品属性等。还有是各个业务对同一名称的定义也会不一样，库存的长宽高是商品属性，而物流的长宽高是整个包裹的占用空间。
在我司的业务中，虽然没有用到 DDD 的领域划分，但我们用的是业务模块划分，物流模块中只有商品的对物流有用的部分属性，这样看来也符合 DDD 领域模型划分的做法。
菱形对称架构模式
将限界上下文内部分为内部领域层和外部网关层。网关又分为南向和北向网关，南向体现了抽象的设计思想，将抽象与实现分离；北向体现了封装的思想，根据通信方式不同分为远程服务和应用服务。
系统上下文
系统级别。它的存在就是为了将各个系统清晰的划分。
上下文映射
各个上下文中难免有模糊地带，这些地方如果不加以管理，会陷入混乱，需要引入上下文映射让其恢复秩序。
为了是让跨上下文协作变的可控。
防腐层
为了防止上游的变动影响下游，引入一层来防止受到影响，只要防腐层的接口不变，下游的限界上下文就不会受到影响。
消息契约
命令：客户端发起的一个动作，要求服务完成某些操作，会更新系统的状态，写操作；这类请求一般以Command结尾，命令响应以 Result 结尾
查询：客户端发起的一个请求，查看，没有副作用，对比 HTTP 中的 get 请求；这类请求一般以Request结尾，响数据应以 Response 结尾
事件：客户端发起的一个触发器，用于告知发生了什么事
实体
值对象
聚合根
领域服务
领域事件
资源库
工厂
领域驱动设计引入了分层架构，严格规定了分层的含义。将业务逻辑封装到领域层（domain layer）中，支撑业务逻辑放到基础设施层（infrastucture layer）,领域层的上面应用层（application layer）有两个作用：一是作为业务逻辑的外观（facade）暴露接口，二是作为业务逻辑和技术实现的黏合剂。
抽象的资源库接口放在领域层，实现放在基础设施层，领域只需调用接口就行，具体实现由基础设施层确定。
例如保存订单调用 orderRepository.save(Order order) 领域层不需要知道它用哪种存储服务
若有收获，就点个赞吧
0 人点赞
