什么是企业技术架构

 建议初学者阅读“编程规则”，资深者阅读“软件之道”

      最近看了几本关于架构的书籍，看来架构做为一个概念和体系还很年轻，还不是很清晰。

      首先架构的概念太宽泛，各领域都有架构的概念，仅就软件领域而言，也包括：

              业务架构、应用架构、技术架构、数据架构等。

       本文仅就技术架构而言，有认为架构只是过程而非结果的，有认为架构只是图表的，有认为架构是路线和思想的。我认为这只是概念层的架构，实在的、落地的、具体的、科学的架构才是美丽的架构，否则只是“浮云”啊。

       因此我认为：架构是支持某种类型软件运行的虚拟机和构建器。参考：“应用架构的特征”、“平台之美”

       架构不是面向具体功能的，而是面向全部需求的需求(元需求)，关注设计的设计（元设计），解决开发之共性，简化开发之过程，提供应用之舞台，可谓应用之母也。

       架构是体系化的，完备的，能够满足一类软件全部元需求的运行平台和构建平台，具体功能运行于其上，可以做到一通百通。

   我预言：未来二十年将是各类架构平台软件诞生并逐步成熟的年代。它将逐步超过数据库、中间件的软件市场份额。

           下面给出一个富客户端企业技术架构的简图供参考：

      

        一般架构为三层，即表示层，领域层和数据层，但真实的企业级软件架构要求更细致，领域层会进一步分解为中台和后台，中台会实现诸多企业级应用系统的元需求，如：文件传输、消息发布、录入复核、工作流转、运行监控等非业务性需求。

       虚拟AE层实现架构与具体技术的隔离，这是保障应用不受具体技术环境影响的重要设计。

   参阅：软件领域十大命题

     有朋友希望推荐架构方面的书，我在这里回答一下，首先如果你搞开发不满3年，建议你先不要研究架构，认真学习一下“代码整洁之道”或“编程规则”（该文就借鉴了许多该书的观点），这对你成长为架构师会有帮助，能够写出结构优美的代码是成为架构是的第一步。

   另外，架构师需要很综合的能力，要了解软件、硬件、网络、数据库、中间件、工作流等的基本原理，欣赏绘画、阅读历史、研究哲学，这样你才能够逐步具备进行企业级应用架构设计的能力，学习一下“系统架构设计师教程”也是不错的选择。

   事实上，在许多国际水准的软件企业，有10年开发经验的，才有资格进入产品开发部，有15年经验才允许做架构层面的设计，但在我国10年还在搞开发的人几乎不存在了，10年如果还在搞开发会被很多人认为是没出息的！这几乎形成了一种文化，这应该给我们深刻的启发和反省。

       目前“架构”还很年轻，概念还比较乱，确切地说还没有很好的书籍（有些书籍甚至会误导你，书不是看的越多越好，一定要选择，要看经典，“人月神话”、“人件”一定要看，不过“人件”读起来比较涩，你可以参考我为此书写的精简版，你最好把它推荐给你的老板，让他明白软件开发人员是智力工作者，不是“码工”）。“架构之美”并没有名字那么美，尤其不要被前面几位写推荐序的忽悠了，该书1~30页是值得认真阅读的。