人人都是架构师

http://www.devdiv.com/blog-1895-57919.html

架构是什么？业界并没有权威的说法。

架构作为名词与结构相关，将产品分解为一系列组件、模块和交互。作为动词，是关于交流愿景和引入技术领导力的，简而言之，架构就是结构和愿景。

关于架构

应用程序的架构着重于软件和代码的组织，每个工程师的代码都是有架构的，只是自发和自觉的区别；系统架构描述从组件和服务到子系统等更高层次的抽象含软硬件，从代码结构到生产环境，与软件系统重要元素相关的所有东西就是软件架构。
企业架构是一个截然不同的概念，指的是战略而非代码。

所有架构都是设计，但并非所有设计都是架构。架构反映了一个系统的重要设计决策，重要性通过改变的成本来衡量，包括系统的形态，结构，技术选择，框架选择，设计方法和模式的选择等。

敏捷与架构并不冲突，敏捷中的架构是在独特环境下量化所需的预先设计，架构提供了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。