关于分布式的系统的到DDD领域驱动设计模式的理解

目前市面常用的两套分布式系统框架：

1.zookeeper+dubbo组合

2.SpringCloud全家桶

简单介绍说明一下框架（如若真正有兴趣的人百度上有一大把的说明可以查看， 我这里只是简单的阐述一下个人的理解）

zookeeper 是一个分布式服务应用的协调服务，其功能包括了：配置维护、域名服务、分布式同步、组服务等。

dubbo 是按照分层的方式来架构的分布式服务框架，从服务模型的角度来，要么是提供服务，要么是消费服务，所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色

SpringCloud是一整套的分布式服务的解决方案，里面有很多使用的组件，常用的用组件

• 服务发现——Netflix Eureka
• 客服端负载均衡——Netflix Ribbon
• 断路器——Netflix Hystrix
• 服务网关——Netflix Zuul
• 分布式配置——Spring Cloud Config

2套框架的区别：

1.dubbo 仅仅是一个RPC框架，采用netty通信通过二进制进行传输 ，占用的宽带相对较小，SpringCloud采用的是http进行通讯且一般使用json报文。

2.dubbo 的依赖jar包版本依赖管理方式比较麻烦，服务A 新增一个接口方法，需要打包给服务B 应用才能调用否则会报编译出错，使用在deploy的时候要小心谨慎， SpringCloud 一般用fegin（底层也还是用的ribbon ，且使用起来更优雅） 和 ribbon 两种方式实现restful交互。

3.dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研

 

DDD领域驱动设计模式

你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。

本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域事件发布和订阅等；第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容；最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。

目标

本文采用 DDD（领域驱动设计）作为微服务设计指导思想，通过事件风暴建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义符合 DDD 分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程，指导团队按照 DDD 设计思想完成微服务设计和开发。

通过领域模型和 DDD 的分层思想，屏蔽外部变化对领域逻辑的影响，确保交付的软件产品是边界清晰的微服务，而不是内部边界依然混乱的小单体。在需求和设计变化时，可以轻松的完成微服务的开发、拆分和组合，确保微服务不易受外部变化的影响，并稳定运行。

适用范围

本文适用于按照 DDD 设计方法进行微服务设计和开发的项目及相关人员。

以下情况不适用：

1. “我们的目标是按期盖出一栋大楼来，不要跟我提什么方法，有这啰嗦的时间，还不如抓紧点时间搬砖，把楼给我快点盖好！”。

2. “我的工作就是让软件运行起来，能工作一切就 OK！我不需要那么多约束，什么设计方法、扩展性、业务变化、领域模型、响应能力与我无关。别耽误工期啦！先上线再说！”。

3. “好的软件是自己演进出来的，我们不需要设计！”。

哈哈，开个玩笑啦！其实设计不会花太多时间的！

不耽误大家时间了，言归正传。

DDD 分层架构视图

DDD 分层架构包括：展现层、应用层、领域层和基础层。

DDD 分层架构各层职能如下：

展现层

展现层负责向用户显示信息和解释用户指令。

应用层

应用层是很薄的一层，主要面向用户用例操作，协调和指挥领域对象来完成业务逻辑。应用层也是与其他系统的应用层进行交互的必要渠道。应用层服务尽量简单，它不包含业务规则或知识，只为下一层的领域对象协调任务，使它们互相协作。应用层还可进行安全认证、权限校验、分布式和持久化事务控制或向外部应用发送基于事件的消息等。

领域层

领域层是软件的核心所在，它实现全部业务逻辑并且通过各种校验手段保证业务正确性。它包含业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。它负责表达业务概念、业务状态以及业务规则，具体表现形式就是领域模型。

基础层

基础层为各层提供通用的技术能力，包括：为应用层传递消息、提供 API 管理，为领域层提供数据库持久化机制等。它还能通过技术框架来支持各层之间的交互。

服务视图

微服务内的服务视图

微服务内有 Facade 接口、应用服务、领域服务和基础服务，各层服务协同配合，为外部提供服务。

1、接口服务

接口服务位于用户接口层，用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给应用层。

2、应用服务

应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。

应用层的服务包括应用服务和领域事件相关服务。

应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。

领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。

3、领域服务

领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。

领域服务对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。

为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。

为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。

4、基础服务

基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。