引言

不知不觉，已经第十周了时间真的好快 这周讲的是微服务和领域驱动设计DDD。

微服务

微服务架构设计

附上以前整理的微服务架构图



单体服务存在的问题

• 部署困难

• 代码分支管理困难

• 数据库资源耗尽

• 新增业务困难

解决方案

服务拆分，将业务拆分成职责单一的子服务独立部署。

微服务框架

解决微服务落地的问题：



• 服务注册与发现、服务调用

• 失效转移

• 负载均衡：微服务网关

• 高效的远程通信：服务网格

• 对应用侵入最小

• 版本管理



微服务架构落地

业务先行，先要用理顺业务的边界和依赖，并进行合理拆分；

技术只是手段，先理清要解决的问题及实现的目的，再着手微服务设计和实施。



领域驱动设计DDD

贫血VS充血

贫血：传统Service、Dao只有方法，没有数值成员变量，而方法传递的数值对象又没有方法，因此事务脚本称为贫血模型。

充血：领域模型的对象既包括了数据，也包括了计算逻辑，称为充血模型。

子域

领域细分，子域



界限上下文

界限上下文与子域一对一，限定了领域边界，任何领域对象只在其边界内部有确切含义



上下文映射

不同子系统或模块间有各种的交互合作，DDD使用上下文映射来设计这种交互



实体

领域模型对象也称为实体。唯一、具有一个唯一标识。最重要的是确定实体承担什么职责，不承担什么职责。

值对象

值对象是唯一且不可变的。

聚合

聚合是关联对象的集合，将其作为一个单元来处理数据变更。每个集合都有一个根和边界，边界定义了聚合内部的内容。根是聚合中包含的单个特定实体。

聚合根：将多个实体和值对象聚合在一起的实体。

DDD分层架构

用户接口层->应用层->领域层

DDD六边形架构

领域模型不动，外部适配不同接口形式