架构的驱动力：
-
功能需求：需求驱动架构。不管怎么捕捉和记录需求（比如，用户故事、用例、需求规格书、验收测试等），你都要大概知道你在构建什么。
-
质量属性：非功能需求（比如，性能、可扩展性、安全等）通常是技术方面的，也很难改造。理论上，这些都需要体现在初始的设计中，忽视这些属性会导致软件系统要么做得不够，要么做得太过。
-
约束：约束普遍存在于现实世界，包括批准的技术清单、规定的集成标准、目标部署环境、团队规模等。再说一次，不考虑这些会导致你交付的软件系统与环境不匹配，增加不必要的摩擦。
-
原则：是在试图为软件提供一致性和清晰度时你想要采用的东西。从设计的角度来看，这包括你的分解策略（比如，层、组件和微服务的对比）、关注点分离、架构模式等。明确概述一套初始的原则至关重要，这样构建软件的团队才会朝着同一方向出发。
C4理论：
软件系统由多个容器构成，容器又由多个组件构成，组件由一个或多个类实现。大多数软件系统都可以用这种简单的逻辑结构单元的层级关系来建模。
-
类：对我们大多数人来说，在一个面向对象的世界里，类是软件系统的最小结构单元。
-
组件：组件可以想象成一个或多个类组成的逻辑群组。比如，其他组件可以使用审计组件或认证服务，来确定对特定资源的请求是否放行。组件通常由多个类在更高层次的约束下组合而成。
-
容器：容器是指一个在其内部可以执行组件或驻留数据的东西。它可以是从网络或应用服务器直到富客户端应用或数据库的任何东西。作为整个系统的一部分，容器通常是可执行文件，但未必是各自独立的流程。比如，我把每个Java EE网络应用或.NET网站都看作一个独立的容器，不管它们是否运行在同一个物理服务器流程中。从容器的角度理解一个软件系统的关键在于，任何容器间的通信可能都需要一个远程接口，比如SOAP网络服务、RESTful接口、Java RMI、Microsoft WCF、报文，等等。
-
系统：系统是最高的抽象层次，代表了能够提供价值的东西。一个系统由多个独立的容器构成，例如金融风险管理系统、网络网银行系统、网站等。