什么是软件架构
概念
软件架构的实质就是规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式。
软件架构的目的
在日常开发中更好的对组件进行研发、部署、运行以及维护
软件架构的目标
软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本
独立性
保留可选项
一个设计良好的架构应该通过保留可选项的方式让系统在任何情况下都能方便的做出必要的变更。
按层结构
架构师应该知道整个系统的基本设计意图
如何理解这句话呢？我的理解是：架构师应该需要知道该架构是解决什么业务问题的？需要有明确的业务问题作为架构设计的出发点
解耦
- 源码层次结构：单体结构
- 部署层次：jar、DDL底层还是在同一个地址空间，彼此通过函数调用或者socket通信
- 服务层次：微服务
重复
如果两段代码看起来重复的代码它们走的不同的演进路线，也就是说他们有着不同的变更频率和变更原有，那么这两段代码就不是真正的重复
划分边界
作用
划分边界的作用是将软件分割成各种元素，以便约束边界两侧之间的以来关系
注意点
划分边界主要考虑的是业务需求，尽可能不依赖这些细节部分比如框架、数据库、web服务器、工具库等
插件式架构
系统的核心业务逻辑必须和其他组件隔离，保持独立，而这些其他组件要么可以去掉要么是有多种实现
如何理解呢？系统的核心逻辑应该是保持基本的函数、输入、输出，不要依赖其他的组件比如数据库、web层等，如果要依赖数据库应该使用中间服务service将数据查询层隔离，底层数据库即使切换也不影响核心业务逻辑
核心
单一职责的作用就是告诉我们应该在哪里划边界线
画边界线需要先将系统分割成组件，其中一部分是系统的核心业务逻辑，而另一部分是与核心业务逻辑无关但负责提供必要功能的插件
依赖箭头应该由底层具体实现指向高层抽象的方向
边界剖析
系统架构中最强的边界形式就是服务
策略与层次
每一层都是按照单一职责原则进行设计
一条策略距离系统的输入/输出越远，它所属的层次就越高
底层组件应该成为高层组件的插件
业务逻辑
业务实体
业务实体这个概念应该只有业务逻辑，没有其他，比如操作mysql、mq、缓存redis等操作，数据层的操作应该通过接口隔离，业务逻辑只关心操作的数据对象，底层使用的数据库不需要关心。
业务实体这个概念只要求我们将关键业务数据和关键业务逻辑绑定在一个独立软件模块内
用例
用例本质是关于如何操作一个自动化系统的描述，定义了用户需要提供的输入数据、输出数据以及产生输出应该采取的处理步骤
用例本身也是一个对象，该对象中包含一个或多个实现了特定应用场景的业务逻辑函数
用例属于底层概念、业务实体属于高层概念；用例靠近系统的输入和输出，一般是controller层；业务实体是适用于多个应用情景的一般化概念
用例依赖于业务实体，而业务实体不依赖于用例；用例----->业务实体
请求和相应模型
请求响应模型要与业务实体隔离开，要基于单一职责和共同闭包原则设计，避免请求响应的变更影响业务实体
总结
业务逻辑应该保持纯净，不要掺杂用户界面或者所使用的数据库相关的东西
业务逻辑应该是系统中最独立、复用性最高的代码
整洁架构
架构的设计目标
按照不同关注点对软件进行切割
按照架构设计出来的系统特点
- 独立于框架
- 可被测试
- 独立于UI
- 独立于数据库
业务实体
封装的是整个系统的关键业务逻辑，一个业务实体既可以是一个带有方法的对象，也可以是一组数据结构和函数的集合
用例
软件的用例层中通常包含的是特定应用场景下的业务逻辑，这里面封装并实现了整个系统的所有用例
接口适配器
软件的接口适配器层中通常是一组数据转换器，它们负责将数据从对用例和业务实体而言最方便操作的格式
不完全边界
不要预测未来的需要
行动
将系统分割成一系列独立编译的组件之后再把他们构成成一个组件，从实际出发就是分好模块之后，将这些模块再合为一个大模块作为编译和部署的单位。
总结
架构师的职责就是预判未来哪里有可能会需要设置架构边界
层次与边界
过度的设计往往比工程设计不足还要糟糕
软件架构师需要评估成本，决定哪里设计架构边界，以及实现这个边界的成本
服务：宏观与微观
面向服务的架构以及微服务架构为什么流行？因为服务之间是强隔离的，服务可以独立开发和部署
微服务本身是一套架构，但是微服务组合形成的整体也是一个架构，因为独立微服务需要考虑考虑边界条件，是否需要独立部署，需要从单一职责考虑
系统架构都是由跨越边界的函数调用来定义的，并且整个结构都必须遵守依赖关系原则
服务边界并不能代表系统的架构边界，服务内部的组件边界才是
