《架构整洁之道》读书笔记（二）
1、软件架构的目标
终极目标:用最小的（人力，资源）成本来满足构建和维护该系统的需求
最大化程序员的生产力，同时最小化系统的总运营成本。最大限度地降低构建和维护一个系统所需的人力资源
支撑软件系统的全生命周期，设计良好的架构让系统便于理解、易于修改、方便维护，并能轻松部署。
开发阶段：组件不要使用大量复杂的脚手架；不同团队负责不同的组件，避免不必要的协作。
部署阶段：部署工作不要依赖成堆的脚本和配置文件；组件越多部署工作越繁重，而部署工作本身是没有价值的，做的越少越好，所以要减少组件数量。
运行阶段：架构设计要考虑到不同的吞吐量、不同的响应时长要求；架构应起到揭示系统运行的作用：用例、功能、行为设置应该都是对开发者可见的一级实体，以类、函数或模块的形式占据明显位置，命名能清晰地描述对应的功能。
维护阶段：减少探秘成本和风险。探秘成本是对现有软件系统的挖掘工作，确定新功能或修复问题的最佳位置和方式。风险是做改动时，可能衍生出新的问题。
2、软件架构是什么
规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式
3、划分边界
架构师追求的目标是最大限度地降低构建和维护一个系统所需的人力资源。
最消耗人力资源的是什么？
系统中存在的耦合：
1、过早做出的、不成熟的决策所导致的耦合
2、是那些与系统的业务需求无关的决策，包括要采用的框架、数据库、Web服务器、工具库、依赖注入等。
解决方案：通过划清边界(个人理解边界，即是职责的问题)，可以推迟和延后一些细节性的决策，最终会为我们节省大量的时间、避免大量的问题。
4、插件式架构
1、软件开发技术发展的历史：就是一个如何想法设法方便地增加插件，从而构建一个可扩展、可维护的系统架构的故事。
2、系统的核心业务逻辑必须和其他组件隔离，保持独立，其他组件要么可以去掉的，要么有多种实现的。
个人思考：
1、插件的本质是， 将大的职责组件分开独立的小的职责组件(插件)， 另外一点必须有维护组件(串联起来小的组件， 可以工作)， 有新的需求， 可以增加(扩展)小的组件；有新的外围框架或是中间件，可以方便切换！
2、核心业务逻辑， 与依赖外部服务或是组件分开，再包装一层，可以方便替换
3、对依赖反转原则（DIP）和稳定抽象原则（SAP）的具体应用
5、业务逻辑
业务逻辑是一个系统存在的意义，属于核心功能，是系统用来赚钱或省钱的那部分代码，是整个系统中的皇冠明珠。
业务逻辑应该保持纯净，不要掺杂用户界面或者所用数据库相关东西。
理想情况下，代表业务逻辑的代码应该是整个系统的核心，其它底层概念的实现应该以插件形式接入系统中。
业务逻辑应该是系统中最独立、复用性最高的代码。
翻译 朗读 复制 正在查询，请稍候…… 重试 朗读 复制 复制 朗读 复制 via 谷歌翻译（国内） 译
浙公网安备 33010602011771号