人人都是架构师
架构是什么？业界并没有权威的说法。
架构作为名词与结构相关，将产品分解为一系列组件、模块和交互。作为动词，是关于交流愿景和引入技术领导力的，简而言之，架构就是结构和愿景。
关于架构
应用程序的架构着重于软件和代码的组织，每个工程师的代码都是有架构的，只是自发和自觉的区别；系统架构描述从组件和服务到子系统等更高层次的抽象含软硬件，从代码结构到生产环境，与软件系统重要元素相关的所有东西就是软件架构。
企业架构是一个截然不同的概念，指的是战略而非代码。
所有架构都是设计，但并非所有设计都是架构。架构反映了一个系统的重要设计决策，重要性通过改变的成本来衡量，包括系统的形态，结构，技术选择，框架选择，设计方法和模式的选择等。
敏捷与架构并不冲突，敏捷中的架构是在独特环境下量化所需的预先设计，架构提供了xDD敏捷方式的分界线。主要思想是集中主要的高层次关键需求，规避风险，然后迭代和增量。敏捷是相对的，好的架构能够带来敏捷，尤其是微服务架构。
非功能性需求
需求是最重要的事情，失去了功能，失去了客户的价值，软件将一无是处。
然而，功能的实现只是架构的开端。
架构首先来自需求，需求驱动架构，然后非功能性需求反映服务等级，面对客观环境的约束，自行引入的架构实现原则，是在高层次以上对需求、约束、和原则的理解和把握。
非功能性需求也可以称为质量属性，我所了解的非功能性需求主要有：
- 性能：响应时间或延迟
- 可伸缩性：更多用户，请求和数据的处理能力
- 可用性：99.9%意味着每天一分钟故障
- 安全性： 可以参考OWASP，open web application security project
- 灾难恢复：业务连续性过程
- 可访问性：www.w3.org/standards/webdesign/accessibility
- 监测：只读视图
- 管理：操作视图
- 审计：日志及虚拟货币的对账
- 灵活性：非技术人员修改业务规则的能力
- 可扩展性：可以做现在还不能做的事情
- 可维护性：可读性，可持续发展
- 法律规则：如隐私
- 国际化i18n
- 本地化i10n
约束
时间和预算是约束的基本条件。
技术约束
技术清单，现有系统的互操作性（兼容性），目标部署平台，技术成熟度（保守），开源技术，供应商关系（阿里云，还是AWS），过去的失败，内部知识产权
人员约束
团队规模，技能，团队扩展的速度，咨询和培训，运维团队的技能
组织约束
企业战略的影响，办公室政治的影响
约束条件也是有优先级的。
原则
开发原则
编码标准和规范，自动化单元测试，静态分析工具
架构原则
- 分层策略，如UI组件里没有数据访问的逻辑
- 业务逻辑的位置：
- 高内聚、低耦合：解耦合可以推迟技术决策的时间
- 无状态组件：可伸缩性的瓶颈
- 存储过程：爱恨交加
- 域模型：面向对象的丰富程度
- http会话的使用程度：少用
- 始终一致和最终一致： 一般趋向于数据的最终一致性
- 不/使用ORM
- 依赖注入
风险
架构包含技术的选择，更多分层等于更高的复杂度，但是轻量级协同设计可以提高质量。最佳实践也是有使用条件限制的，面对架构要用于质疑。
系统的最大风险
外部接口是系统风险最高的部分之一。
- 关键的外部接口有哪些？接口的技术定义是什么？
- 哪些队列是通信组件？消息的格式是什么？
- 同步还是异步？异步连接是否有保障？能否乱序传输？
- 接口是否幂等？接口的可用性、性能、可伸缩性、安全性？
- 接口的所有权属？版本的升级处理？服务级别？
系统的常见风险
除了外部接口之外，其他的常见风险如下：
- 组件运行过慢
- 组件无法伸缩
- 关键组件崩溃
- 单点故障
- 数据被破坏
- 基础设施故障
- 磁盘满
- 新技术过于复杂
文档
架构需要以文档的方式回答质疑。
代码不会讲述完整的故事，轻量级文档来描述代码之外的问题，如
- 这是关于什么的？希望能做什么？
- 质量属性？约束？原则？
- 软件架构？外部接口？
- 数据（数据比软件本身更重要。）？
- 基础设施架构？
- 部署？运营和支持？
- 决策日志
……
总而言之，架构不论你关注与否都在那里，每个人都是架构师，只是关注的层面和视角不同而已。
Without architect consideration，the software is a big mall of mud。
