架构是什么
架构作为名词解释时，概括起来都与结构有关：将产品分解为一序列组件、模块和交互。
架构作为动词来解释时，包括了理解你需要构建什么、设定愿景以便进行构建和做出恰当的设计决策。所有这些都以需求为基础，因为需求驱动架构。关键在于，架构是关于交流愿景以及引入技术领导力的，这样参与构建产品的每个人都能理解这个愿景，并为产品的成功做出积极贡献。
不论何种领域的架构，其实主要就是结构和愿景。
架构分类
应用程序架构的关注点是应用程序，通常包括将应用程序结构为类和组件，确保设计模式正确应用，构建或使用框架，等等。本质上，应用程序架构谈论的是软件设计的低级别切面，通常只考虑单一的技术栈。应用程序架构着重考虑软件和代码组织。
系统架构是更大规模的应用程序架构。大多数软件系统实际上是由横跨不同层次和技术的多个应用程序组成。系统架构还关注互操作性和与环境中其他系统的集成。系统架构描述为从组件和服务到子系统等高层次的抽象。系统架构的定义大多数还包括了软件和硬件。
软件架构就是应用程序和系统架构的结合。从代码结构和基础到将代码成功部署到生产环境，与一个软件系统重要元素相关的所有东西就是软件架构。
企业架构一般是指整个组织的中心工作，着眼于如何组织和利用人员、流程和技术来使企业有效和高效地工作。它是关于企业如何分成组或部门，业务流程如何在这上层运作，以及技术如何支撑这一切。
好的架构带来敏捷。
架构 VS. 设计
作为名词，设计是指一个系统内命名的结构或行为，解决或有助于月解决该系统的一个或多个问题。因而，设计代表了潜在的决策空间中的一个点。
所有架构都是设计，但并非所有设计都是架构。
架构反映了使一个系统成型的重要设计决策，而重要性则通过改变的成本来衡量。
尽管“重要决策”没法彻底消失，但能通过架构分层等多种策略来改变。软件系统架构流程的一部分就是搞清楚哪些是重要的及为什么。
思考软件架构的好处
- 让团队跟随一个清晰的愿景和路线图，无论这个愿景是一个人所有还是整个团队共有；
- 技术领导力和更好的协调；
- 与人交流的刺激因素，以便回答与重要决策、非功能需求、限制和其他横切关注点相关的问题；
- 识别或减轻风险的框架；
- 方法和标准的一致性，随之而来的结构良好的代码库；
- 正在构建的产品的坚实基础；
- 对不同的听众，以不同层次的抽象来交流解决方案的结构。
C4：语境、容器、组件和类
软件的静态视图：
-
语境：设定场景的高层次图，包括关键的系统依赖和参与者。
语境图帮助回答下面的问题：
- 我们构建的（或已经构建的）软件系统是什么？
- 谁会用它？
- 如何融入已有的 IT 系统？
-
容器：荣企图显示了高层次的技术选择，容器如何分担职责、如何通信。
- 软件系统的整体形态是什么样的？
- 高层次技术决策有哪些？
- 职责在系统中如何分布？
- 容器之间如何相互交流？
- 为了实现特性，作为一个开发者，我需要在哪里写代码？
-
组件：组件图可以让你看到每个容器的关键逻辑组件及之间的关系。
- 系统由哪些组件/服务组成？
- 在高层次上，系统如何工作是否清晰？
- 所有组件/服务都有一个家吗（即驻留在一个容器中）？
-
类：可选的细节层次。
原则
约束通常是强加于你的，而原则是你为了将一致性和清晰度引入最终代码库而想采用的原则（如编码规范、自动化测试等）或架构的原则（如分层策略，架构模式等）。
欢迎关注我的微信公众号: coderbee笔记，可以更及时回复你的讨论。
