アーキテクチャは、現在のアーキテクチャの概念（道路）より少なく、我々はシステムアーキテクチャに基づいて、いくつかの実用的かつ大規模な電気のプロバイダを考えると、私たちはどのようなアーキテクチャの概念、希望の話を議論する実用的な操作（手術）より多くの記事を、議論されていますこれは、アーキテクチャのすべての人の理解を促進するための触媒として機能することができます。
道路は何で、手続きは何ですか？道路は、物事の発展の法則の本質である、手術は物事の発展に具体的な方法です。法律は、すべての道はローマに通ず、唯一の方法がたくさんある道は手術である、ローマの道です。あなたはどこローマで事前に知っていれば、道路ベースは、手術は、方法ですが、その後、舗装道路、ルルが接続されています。彼らは建築の本質を理解できるかどうかのアーキテクチャでは、あまりにも、それは既存の実用的かつ理論的なフレームに固執せず、問題を解決するための最も直接的な方法で、何のストロークがトリックを獲得していません。内容は、アーキテクチャの性質上、このようなアーキテクチャのレルムとして、クライアント、建築家のコンピテンシーモデルのアーキテクチャが含まれます。
アーキテクチャの本質
任意のシステム、自然の状況下で、順序から科学的根拠である障害にあり、熱力学第二法則によれば、自然のすべての自発的プロセスが指向性を有する、単離されたシステムは、順に無秩序になるであろうそれは、最終的に静止状態をそのエントロピーを増加していきます。しかし、外の世界は秩序を確保し、生き残るためにそれ自体で「負のエントロピー」を作成、生物学的な、活発な新陳代謝と対話することができます。
同様に、ソフトウェアシステム、より多くの機能として、呼び出しはシステム全体が徐々に、断片化し、より多くの混沌、そして維持し、拡張することが最終的にできない、劇的に増加し、その成長の残忍な期間の後にシステムだけでなく、タイムリーな介入の必要性無秩序避けます。
システムアーキテクチャの性質は秩序再建、「エントロピー」の減少システムであり、システムが進化しています。
そのアーキテクチャは、それを注文する障害を達成する方法ですか？基本的なツールは、調和を分割された第1のシステムを壊す、その後、再び組み立てています。
サブプロセスは、サブシステム/モジュール/コンポーネントにスプリットタイムをシステムに分割することですあなたがお互いの境界線を分割することができます前に、我々は最初の合理的な分割を達成するために、各コンポーネントの配置の問題を解決しなければなりません。最終的な結合は比較的に言えば、と一体化分離された有機成分の各々、より困難な最初のステップを分割するために、必要とされます。
結果の分割がアジャイル開発を実現する、ビジネスフォーカス、スキル、フォーカスを行うために、開発者を可能にし、結果があるため、ビジネスの俊敏性を達成するために必要で変更することができる柔軟なシステムになるためにバインドされています。
举个例子，在 Web 1.0 时代，一个 ASP 或 JSP 页面里，HTML 和脚本代码混在一起，此时脚本代码越多，系统越混乱（即熵增加），最终连开发者自己都无法理解。此时就需要对系统重新架构，办法是引入 view helper 模式，分离 HTML 和脚本，HTML 成为 view，脚本成为帮助类。然后再简单整合在一起。通过重新分和合，整个系统层次清晰，职责明确，系统的无序度降低，容易扩展。同时不同技能的开发人员， 如 UED 和程序员，可以负责不同部分，有效提高开发效率。
好的架构就像一篇优美的散文，形散神不散，表面看无序，实则高度有序。
架构分类和服务对象
架构一般可分业务架构、应用架构、技术架构，那么它们分别解决什么问题，服务于谁呢？ 我们首先看一个系统落地过程：
对于负责开发的人来说，怕的是业务太复杂，代码逻辑太乱，超出他能理解的范畴，系统无法维护。因此开发的需求是系统整体概念清晰，容易理解，方便扩展。
对于负责运行的机器来说，怕的是业务并发量太大，系统核心资源不够用（如数据库连接）。它希望在业务量增加时，系统能够支持水平扩展，支持硬件容错（如避免单点故障）。
开发的痛点主要由业务架构和应用架构解决，业务架构从概念层面帮助开发理解系统（动态的包括业务流程 / 节点 / 输入输出，静态的包括业务域 / 业务模块 / 单据模型）。
应用架构从逻辑层面帮助开发落地系统（应用种类 / 应用形式 / 数据交互关系 / 交互方式等），整个系统逻辑上容易理解，最近大家谈的比较多的 SOA 即属于应用架构的范畴。
机器的痛点主要由技术架构解决，如技术平台选型（操作系统 / 中间件 / 设备等），部署上希望支持多机房，水平扩展，无单点等。
强调一下，系统是人的系统，架构首先是为人服务的，业务概念清晰、应用逻辑合理、人好理解是第一位的（即系统有序度高）。现在大家讨论更多的是技术 架构，如高并发设计，分布式事务处理等，只是因为这个不需要业务上下文背景，比较好相互沟通。具体架构设计时，首先要关注业务架构和应用架构，这个架构新 手要特别注意。
架构师能力模型
架构师只做分和合的事情，但综合能力要求很高，要求内外兼修，下得厨房，上得厅堂，下图通过典型的架构方式介绍一个架构师的能力要求：
在此基础上，架构师要有技术的广度（多领域知识），又有深度（技术前瞻），对主流公司的系统设计非常了解，知道优劣长短，碰到实际问题，很快有多种方案可供评估。
抽象思维是架构师最重要的能力，架构师要善于把实物概念化并归类。比如面对一个大型的 B2C 网站，能够迅速抽象为采购->运营->前台搜索->下单->履单这几大块，对系统分而治之，庖丁解牛，早已目无全牛。
抽象思维是往高层次的总结升华，由实到虚；而透过问题看本质则是由虚到实，往深层次地挖掘。比如看到一段 java 代码，知道它在 JVM 如何执行；一个跨网络调用，知道数据是如何通过各种介质到达目标 (操作系统内核 / 网卡端口 / 电磁介质等）。透过问题看本质使架构师能够敏锐地发现底层之真实，系统性端到端地思考问题，识别木桶的短板并解决之。
能落地的架构才是好架构，良好的沟通能力确保各方对架构达成共识，愿意采取行动；良好的平衡取舍能力确保架构在现有资源约束下是最合理的，理想最终照进现实。
总结下，架构师的能力要求包括：
- 兼具技术的广度（多领域知识）和深度（技术前瞻）
- 兼具思维的高度（抽象思维）和深度（问题到本质）
- 兼具感性（沟通）和理性（平衡）
架构境界
架构师从境界上由浅到深可以分为四层：第一看山不是山，第二看山是山，第三看山不是山，第四看山是山。
刚接手项目时，对业务不了解，时时被业务方冒出的术语弄得一愣一愣的，如果把现有问题比作山，则是横看成岭侧成峰，根本摸不透，此时看山不是山。
经过业务梳理和对系统深入了解，可以设计出一个屌丝的方案，把各个系统串起来，解决当前的问题，对当前这个山能够看清楚全貌，此时能够做到看山是山。
通过进一步抽象，发现问题的本质，原来这个问题是共性的，后续还会有很多类似问题。设计上进行总结和升华，得出一个通用的方案，不光能解决当前的问题，还可以解决潜在的问题。此时看到的已经是问题本质，看山不是山。
最后回到问题本身，去除过度的抽象，给出的设计简洁明了，增之一分嫌肥，减之一分嫌瘦，既解决当前问题，又保留最基本的扩展，此时问题还是那个问题，山还是那个山。
第一境界给不出合适方案，不表。
第二境界的方案只解决表面问题，往往设计不够，碰到其它类似问题或者问题稍微变形，系统需要重新做。
第三境界的方案往往过度设计，太追求通用化会创造出过多抽象，生造概念，理解和实现均困难，此时系统的无序度反而增加，过犹不及。
第四境界的方案，在了解问题本质的基础上，同时考虑现状，评估未来，不多做，不少做。
佛教讲空和色，色即事物现象，空即事物本质，从这个意义上说，第一重境界无色无空，第二重境界过色，第三重境界过空，第四重境界站在色和空之间，既色又空，不执着于当前，不虚无于未来。
不空不色，既空既色，道法自然，本性如来，架构之髓也。