什么是企业技术架构

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

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

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

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

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

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

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

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

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

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

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

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

参阅:软件领域十大命题

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

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

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

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

你可能感兴趣的:(数据库,系统架构,运维)