架构整洁之道-软件架构(一)
15、什么是软件架构
软件架构的设计分为三个部分：组件切分，组件的组合，组件的通讯。
软件架构的最高优先级时保持系统正常的工作。
一个优秀的软件架构应该时易理解，易修改，方便维护，并轻松部署。
- 开发：从开发角度来讲一个高质量的软件架构方便开发的。但是不同的团队适用不同的软件架构。
- 部署：一个系统的部署成本越高可用性越低，一键部署是设计软件架构的目标。
- 运行：硬件问题可以由摩尔定律来解决，当在性能和可读性做选择的时候可以考虑可读性。
- 维护：文中讲解了 探秘 和风险。探秘就是对现有功能完善和改进。风险就是对功能的完善和改进引入新的问题的风险评估。
- 保持可选项：在设计软件架构的时候保留多的策略，比如使用redis，还是使用Memcache,或者使用第三者，在应用时应该时以策略为基本元素，让细节与策略脱离关系。
这样的设计更多的是在项目后期可以使用更多的信息来进行合理的判断。
所以一个优秀的架构师应该师致力于最大化的可选项的数量。在设计架构应该做到策略和细节分离，尽可能得到更多的信息得到一个相对更合适的设计。
16、独立性
- 系统的用例：架构最终是为了实现业务功能，所以架构必须可以满足业务功能的所有操作，否则架构本身的设计在完善没有任何意义。用例更多的是需求本身。
- 运行：可以灵活应对变化，不仅是对系统行为的变化，还有对系统运行要求的变化。在应对不同请求时 可以通过分别部署的方式来减少非热点业务的浪费。
- 开发：软件架构的影响之一就是组织架构，软件架构是由组织架构决定的，软件架构合理，组织架构不合理时需要调整相应的组织架构。
- 部署：快速部署是架构设计的目标。尽可能地避免依赖配置文件和脚本。
- 保留可选项：
- 软件系统都会随着时间的推移需要不断的迭代和演进，因为业务是在不断的优化和改良的。
- 设计系统之初我们要尽可能的确认目标和范围，尽可能的保证系统职责的所在，以免被变化的需求影响。
- 一个设计良好的系统应该通过保留可选项的方式，让系统在任何情况下都可以方便的做出选择。所以架构设计应该解决的问题不是限制开发。
- 按层解耦：正确规划项目中每个项目的职责。在mvc项目中 数据库的操作放到数据仓储中；业务操作放在controller中；页面操作就是view；每一个领域划分清晰。这样决定了后续系统的复杂度。
- 用例的解耦：更像是一种策略模式 一种是v 1.0 另一种是 0 但是v2.0 的业务实现不引用v1.0的业务实现。但是决定这种模式的前提是v1.0的方法中的职责是单一的。
- 解耦的模式：微服务是一种常见的解耦的方式。但是微服务需要注意拆分的粒度，并不是拆分越细越好，也不是粗犷的拆分。
17、划分边界
- 设计架构应该遵循简单、合适、演进这三个原则
- 对于复杂度比高的系统级方案可以延后在当前业务发展之后可能这种方案并非是一种完美的解决方案。
- 对于数据处理来讲不论是哪一种数据库，但是与业务实现数据操作接口都是一样，比如当前系统使用到的是sql server 根据业务方要求需要换成 mysql ，对于ORM框架来讲只需要调整数据操作接口的策略，使对应的是mysql
- 划分边界的前提是，首先要遵从设计原则，然后拆出核心组件。
18、边界刨析
- 跨边界调用
- 在微服务中的跨服务调用可以简单的称之为跨边界调用。
- 为什么要画边界?边界的划分是为了系统的稳定，比如领域的边界或者服务的边界，对外看来它是相对稳定的，将变更圈禁止于内部。对于调用者和被调用者来说都存在互动都是一个独立的个体，对方的变化不直接影响到被调用者的内部变化。
