软件架构师的主要核心职责不在于功能性的需求如何被实现出来，而是如何监控和设计软件系统的结构使得添加新的功能保持简单、经济和高效。
真正本质的计算机技术和程序设计思想在过去的几十年中并没有发生太大的变化
相对于面向过程的编程范式，面向对象的编程范式其实是限制了程序员必须用间接控制流转移的方法来提高可维护性
函数式编程->数据的不可变性，同样的数据经过同样的处理必然产生同样的输出，同时数据一旦产生就不能被修改了，否则就会有副作用。 流行起来的原因，在于数据的隔离性
软件架构师的任务就是需要清楚地认识到这些编程范式只是在不同的维度上对程序员加了各种各样的约束，以解决它所适应的场景的问题而已。 理顺问题的场景然后清楚地了解编程实现和交付中的各种困难，减小软件扩展和维护的成本，是架构师所面临的最根本的挑战
设计的目标：
- 变更它们的成本很低，因为软件系统总是要添加新功能才更有生命力，修改困难的软件就会被慢慢放弃了
- 理解起来容易，因为维护软件总是需要人来做，而参与其中的人总是在流动的
- 可以被轻易地重用在合适的地方，因为永远也没有人可以预测未来的软件项目需求；重头再写类似的代码的代价又过于高昂
单一原则
一个模块和他相关联交互的Actor只有一个，这样用UML描述模块关系的时候就比较清楚的看出这一原则有没有呗违反了。
使用UML描述
核心的业务规则可以保持稳定，核心业务逻辑层的稳定提炼需要依赖于领域知识
现在我们可以支持在程序执行的过程中，不重启主要系统，而将新开发的功能插入运行的系统中的办法来实现功能的实时更新和扩展， 这种插件化技术甚至在很多开发环境中成为默认的扩展方式；这一技术能够工作的前提是系统的架构必须有良好的考虑和组织
组件内聚原则：
- 重用和发布等同原则 (Common Resue/Release Equivalence Principle)
- 通用闭合原则 (Common Closure Principle)
- 通用重用原则 (Common Reuse Principle)
那么我们需要保证，在组件依赖关系图上，沿着依赖方向组件的稳定性值需要保持递减。 对于违反了这一原则的组件，一个简单的处理方法依然是使用依赖倒置原则创建新的抽象组件，从而避免稳定的组件依赖于不稳定的组件。
策略一旦选定变化起来就比较困难，而细节实现的变化往往容易。 策略的部分包括这些业务规则和过程，而细节则是具体的技术实现、数据库、通信协议、框架、库等。 由于商业业务规则比较稳定而技术的变化比较快，我们需要保持这些稳定的部分，而尽可能的不写死具体实现这些业务规则的技术细节。(关于策略的选取部分)
好的边界划分方法是尽可能降低一些不成熟的决策产生的影响，降低对这些容易变化的决策的依赖。 我们需要在在重要的模块或者子系统和不太重要的子系统之间划分出清晰的边界(边界的制定，又有利于第三方组件的实现)
整洁架构的特征：
- 框架独立性：不依赖于任何库或者软件架构
- 可测试性，各个部分可以独立测试
- 界面隔离和独立，不管是命令行界面系统还是桌面客户端或者是浏览器等技术
- 数据库独立性，可以替换各种SQL数据库，或者是文档数据库等，核心的业务逻辑不依赖于这些具体技术
- 外部代理独立性，核心的业务系统并不知道外围的接口和协议
一定的框架独立性，非常好的可测试性部分，很值得去探究