标签：
http://www.devdiv.com/blog-1895-57919.html
架构是什么？业界并没有权威的说法。
架构作为名词与结构相关，将产品分解为一系列组件、模块和交互。作为动词，是关于交流愿景和引入技术领导力的，简而言之，架构就是结构和愿景。
应用程序的架构着重于软件和代码的组织，每个工程师的代码都是有架构的，只是自发和自觉的区别；系统架构描述从组件和服务到子系统等更高层次的抽象含软硬件，从代码结构到生产环境，与软件系统重要元素相关的所有东西就是软件架构。
企业架构是一个截然不同的概念，指的是战略而非代码。
所有架构都是设计，但并非所有设计都是架构。架构反映了一个系统的重要设计决策，重要性通过改变的成本来衡量，包括系统的形态，结构，技术选择，框架选择，设计方法和模式的选择等。
敏捷与架构并不冲突，敏捷中的架构是在独特环境下量化所需的预先设计，架构提供了xDD敏捷方式的分界线。主要思想是集中主要的高层次关键需求，规避风险，然后迭代和增量。敏捷是相对的，好的架构能够带来敏捷，尤其是微服务架构。
需求是最重要的事情，失去了功能，失去了客户的价值，软件将一无是处。
然而，功能的实现只是架构的开端。
架构首先来自需求，需求驱动架构，然后非功能性需求反映服务等级，面对客观环境的约束，自行引入的架构实现原则，是在高层次以上对需求、约束、和原则的理解和把握。
非功能性需求也可以称为质量属性，我所了解的非功能性需求主要有：
时间和预算是约束的基本条件。
技术清单，现有系统的互操作性（兼容性），目标部署平台，技术成熟度（保守），开源技术，供应商关系（阿里云，还是AWS），过去的失败，内部知识产权
团队规模，技能，团队扩展的速度，咨询和培训，运维团队的技能
企业战略的影响，办公室政治的影响
约束条件也是有优先级的。
编码标准和规范，自动化单元测试，静态分析工具
架构包含技术的选择，更多分层等于更高的复杂度，但是轻量级协同设计可以提高质量。最佳实践也是有使用条件限制的，面对架构要用于质疑。
外部接口是系统风险最高的部分之一。
除了外部接口之外，其他的常见风险如下：
架构需要以文档的方式回答质疑。
代码不会讲述完整的故事，轻量级文档来描述代码之外的问题，如
总而言之，架构不论你关注与否都在那里，每个人都是架构师，只是关注的层面和视角不同而已。
Without architect consideration，the software is a big mall of mud。
标签：
原文地址：http://www.cnblogs.com/feng9exe/p/5571189.html
