一个系统的架构是由一系列软件组件以及它们之间的边界共同定义的。
“系统”有没有规模的含义呢？整洁架构中的系统是有的，而且其规模远不止于应用。“组件”与“边界”共同孕育了聚合、解耦合、依赖、层次等概念。
对于目前的我来说，框架就等同于生产力。然而在整洁架构中，应用程序框架是实现细节。分歧的根源是什么呢？是思维差异导致的！我是个模块级的程序员，关注工具之用。
文摘
软件项目是具有递归（recursive）和分形（fractal）特点的，最终都要由一行行的代码组成。脱离了一行行的代码，脱离了具体的细节设计，架构设计就无从谈起。
今天的软件与过去的软件本质上仍然是一样的，软件架构的规则是相同的，软件架构的终极目标是用最小的人力成本来满足构建和维护该系统的需求。
程序是由顺序结构、分支结构、循环结构和间接转移这几种行为组合而成的，无可增加，也缺一不可。软件架构的三大关注重点：功能性、组件独立性以及数据管理。
结构化编程对程序控制权的直接转移进行了限制和规范。
面向对象编程对程序控制权的间接转移进行了限制和规范。
函数式编程对程序中的赋值进行了限制和规范。
组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。
SOLID原则应该直接紧贴于具体的代码逻辑之上，这些原则是用来帮助我们定义软件中的组件和模块的。
REP（复用/发布等同原则）：软件复用的最小粒度应等同于其发布的最小粒度。
CCP（共同闭包原则）：应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中。
CRP（共同复用原则）：不要强迫一个组件的用户依赖他们不需要的东西。
ADP（无依赖环原则）：组件依赖关系图中不应该出现环。
SDP（稳定依赖原则）：依赖关系必须要指向更稳定的方向。
SAP（稳定抽象原则）：一个组件的抽象化程度应该与其稳定性保持一致。
一个项目在组件结构设计上的重心是根据该项目的开发时间和成熟度不断变动的，我们对组件结构的安排主要与项目开发的进度和它被使用的方式有关，与项目本身功能的关系其实很小。
所有的软件系统都可以降解为策略和细节这两种主要元素。策略体现的是软件中所有的业务规则与操作过程；细节则是指那些让操作该系统的人、其他系统以及程序员们与策略进行交互，但是又不会影响到策略本身的行为。软件架构师的目标是创建一种系统形态，该形态会以策略为最基本的元素，并让细节与策略脱离关系，以允许在具体决策过程中推迟或延迟与细节相关的内容。
边界的作用是将软件分割成各种元素，以便约束边界两侧之间的依赖关系。
一条策略距离系统的输入/输出越远，它所属的层次就越高，而直接管理输入/输出的策略在系统中的层次是最低的。
业务实体中包含了一系列用于操作关键数据的业务逻辑。用例本质上就是关于如何操作一个自动化系统的描述，它定义了用户需要提供的输入数据、用户应该得到的输出信息以及产生输出所应该采取的处理步骤。一个良好的架构设计应该围绕用例来展开，这样的架构设计可以在脱离框架、工具以及使用环境的情况下完整地描述用例。
软件架构师必须仔细权衡成本，决定哪里需要设计架构边界，以及这些地方需要的是完全的边界，还是不完全的边界，还是可以忽略的边界。