image.png
第4章：架构
拆书稿
一、架构模式与架构风格
分层
- 定义说明
将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层的依赖，因为他们不属于业务逻辑。每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。
- 一个典型的传统分层架构
用户接口层
应用层
领域层
基础设施层
- 依赖倒置原则
定义：
高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
六边形架构
- 定义说明
该架构中存在两个区域，分别是"外部区域"和"内部区域"。
- 外部区域：不同的客户均可以提交输入；
- 内部区域：用于获取持久化数据，并对程序输出进行存储（数据库），或者在中途将输出转发到另外的地方（消息）；
外部与内部之间通过适配器对输入转化，每个客户端都有自己的适配器。
- 注意点
根据用例来设计应用程序，而不是根据需要支持的客户数目来设计。
面向服务架构（SOA）
服务设计原则
- 服务契约
通过契约文档，服务阐述自身的目的与功能
- 松耦合
服务将依赖关系最小化
- 服务抽象
服务只发布契约，而向客户隐藏内部逻辑
- 服务重用性
一种服务可以被其他服务所重用
- 服务自治性
服务自行控制环境与资源以保持独立性，这有助于保持服务的一致性和可靠性
- 服务无状态性
服务负责消费方的状态管理，这不能与服务的自治性发生冲突
- 服务可发现性
客户可以通过服务元数据来查找服务和理解服务
- 服务组合性
一种服务可以由其他的服务组合而成，而不管其他服务的大小和复杂性如何
SOA精神所在
- 业务价值高于技术策略
- 战略目标高于项目利益
RESTful
资源、无状态通信、自描述功能、封装行为
CQRS - 命令和查询职责分离
事件驱动架构
管道和过滤器
读后思考
其实首先要改变的是我们平时开发的思维模式
编码时，通常用两种工作流程：
- 自底向上
先设计数据模型，比如关系型数据库的表结构，再实现业务逻辑。在平时开发同学拿到开发需求后，开始的第一件事情就是："让我先把数据库表字段设计出来吧"。这基本就是大多数开发同学在设计阶段做的事情了。这种方式就是将关注点优先放在了技术性的数据模型上了，而不是代表业务的领域模型。
- 自顶向下
拿到业务需求，先和客户方确定好请求数据格式，设计好请求RESTFUL URL，在实现Controller和service，然后在实现领域模型，最后在来考虑数据库表持久层的设计。
