均为原创，读架构整洁之道的笔记。
首先软件架构师自身需要是程序员，并且必须一直坚持做一线程序员。软件架构师应该是能力最强的一群程序员，在承接编程任务时，还应该逐渐引导整个团队，向一个能够最大化生产力的系统设计方向前进。
也许软件架构师的代码量不是最多的，但是他们必须不停的承接编程任务，如果不亲自承受系统设计带来的麻烦，就体会不到设计不佳带来的痛苦，接着就会迷失正确的设计方向。
软件架构这项工作的实质就是规划如何将系统切分为组件，并安排好组件之间的排列关系，以及组件之间的通信方式。
如果想设计一个便于推进各项工作的系统，其策略就是要在设计中尽可能长时间的保留尽可能多的可选项。
软件系统的架构质量，和该系统是否能正常运行关系并不大，因为世界上有很多架构设计糟糕，但是正常工作的软件系统。麻烦的不是是否能正常运行，而是后续的开发，以及是否能扩展，测试，部署。
软件架构设计的主要目标时支撑软件系统的全生命周期。终极目标时能最大化程序员的生产力，同时最小化系统的总运营成本。
开发（Development）
一个开发起来困难的软件，一般不会有一个长久，健康的生命周期，所以架构的作用时要方便开发团队对它开发。
不同的团队结构应采用不同的架构设计。在小的开发团队中，通常会忽略掉架构，因为架构在前期被认为是一种障碍。
但如果软件是由很多人开发，那么如果没有将系统划分成定义清晰的组件，和稳定可靠的接口，开发工作就没法继续推进。通常会根据团队来划分组件，每个组件归于一个团队负责。当然这并不是最优方案。如果研发团队只受开发进度来驱动的话，架构设计最终一定会倾向于这个方向。
部署（Deployment）
一个系统的部署成本越高，可用性就越低。因此一键式部署应该是我们架构设计的一个目标。很不幸的是，我们开发早期很少会考虑部署的事情，这就会导致一些易于开发，难于部署的系统架构。
比如，早期开发中，可能会使用微服务，边界清晰，接口稳定，利于开发。但是部署时，就会发现太难了，微服务数量多，启动顺序，启动时间，都可能会造成系统出错。
所以，早期就应当考虑部署问题。
运行（Operation）
软件架构对系统运行的影响，远不及它对开发，部署，维护的影响。几乎任何运行问题都可以通过增加硬件的方式来解决，这样就避免了软件架构的重新设计。
基于投入/产出比的考虑，我们的重心应该更倾向于系统的开发，部署，以及维护。
设计良好的系统架构应该可以使开发人员对系统的运行过程一目了然。它应当起到揭示系统运行过程的作用。
维护（Maintenance）
在软件系统所有方面中，维护所需的成本是最高的。因为要满足永不停歇新功能需求和解决层出不穷的系统缺陷。
主要成本集中在两个方面，探秘和风险。
探秘：新增功能，修复功能的最佳方式。
风险：探秘行为，所衍生出的新问题。
但是我们可以通过精雕细琢的架构设计，极大的降低这两个成本。比如切分组件，使用稳定的接口隔离组件等。
保持可选项
正如之前章节所说的，软件有两方面价值，行为价值，和架构价值。而架构价值更为重要，因为它正是软件软的原因。
软，意味着我们需要制作出一种灵活便捷的系统。我们维持软件软的办法，就是尽可能长时间的保留尽可能多的可选项。那么我们到底应该保留哪些选项呢？它们就是那些无关紧要的细节设计。
基本上所有软件都可以降解为两个主要元素。策略与细节。策略指的时业务规则喝操作过程，它时系统存在的价值。
细节则是指与策略无关的，这些东西的变动，不会影响到策略的。比如说数据库选择，框架，交互协议等。
软件架构师的目标是创建一个系统形态。以策略为基本元素，让细节与策略脱离关系，以达到在讨论策略时，可以延迟或推迟细节的相关内容。
比如在开发早期，应当无需选择数据库系统，无需选择面向用户的到底时网页端，还是桌面端，也无需考虑是什么框架，或者是否是依赖注入，这些都是细节。
开发早期，应当专注于策略，并使细节和策略脱钩。我们就可以拜托具体细节的纠缠。这样做，我们还有机会做不同的尝试。
如果已经有人替我们做出了决策呢？比如公司指定了就用某个数据库，或者就用网页。那么优秀的软件架构师会假装这些决策还没有确定。
一个优秀的软件架构师应该致力于最大化可选项数量。
设备无关性
就是代码和业务逻辑，不要和特定的设备或者平台绑定，应当抽象出接口。OCP（开闭原则）。
本章小结
优秀的架构师，应该小心的将软件的高层策略和底层实现隔离开，让策略和细节脱钩。
