《实现领域驱动设计》拆书稿 - 第4章 架构

image.png

第4章：架构

拆书稿

一、架构模式与架构风格

分层

• 定义说明

将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层的依赖，因为他们不属于业务逻辑。每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。

• 一个典型的传统分层架构

用户接口层
应用层
领域层
基础设施层

• 依赖倒置原则

定义：
高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

六边形架构

• 定义说明

该架构中存在两个区域，分别是"外部区域"和"内部区域"。

• 外部区域：不同的客户均可以提交输入；
• 内部区域：用于获取持久化数据，并对程序输出进行存储（数据库），或者在中途将输出转发到另外的地方（消息）；
  外部与内部之间通过适配器对输入转化，每个客户端都有自己的适配器。

• 注意点

根据用例来设计应用程序，而不是根据需要支持的客户数目来设计。

面向服务架构（SOA）

服务设计原则

1. 服务契约

通过契约文档，服务阐述自身的目的与功能

2. 松耦合

服务将依赖关系最小化

3. 服务抽象

服务只发布契约，而向客户隐藏内部逻辑

4. 服务重用性

一种服务可以被其他服务所重用

5. 服务自治性

服务自行控制环境与资源以保持独立性，这有助于保持服务的一致性和可靠性

6. 服务无状态性

服务负责消费方的状态管理，这不能与服务的自治性发生冲突

7. 服务可发现性

客户可以通过服务元数据来查找服务和理解服务

8. 服务组合性

一种服务可以由其他的服务组合而成，而不管其他服务的大小和复杂性如何

SOA精神所在

• 业务价值高于技术策略
• 战略目标高于项目利益

RESTful

资源、无状态通信、自描述功能、封装行为

CQRS - 命令和查询职责分离

事件驱动架构

管道和过滤器

读后思考

其实首先要改变的是我们平时开发的思维模式

编码时，通常用两种工作流程：

• 自底向上

先设计数据模型，比如关系型数据库的表结构，再实现业务逻辑。在平时开发同学拿到开发需求后，开始的第一件事情就是："让我先把数据库表字段设计出来吧"。这基本就是大多数开发同学在设计阶段做的事情了。这种方式就是将关注点优先放在了技术性的数据模型上了，而不是代表业务的领域模型。

• 自顶向下

拿到业务需求，先和客户方确定好请求数据格式，设计好请求RESTFUL URL，在实现Controller和service，然后在实现领域模型，最后在来考虑数据库表持久层的设计。