架构 － 又一个类似与“平台”一样的词汇

　　有一阵子听到大家都在讲“平台”，但是不知道具体什么是平台，经过很多思考后才有了自己的一些较为清晰的认识，见《软件观点 － 平台分类：系统平台、开发平台和开放平台》。除了“平台”这个词曾经让我很迷惑之外，还有一个很重要的词至今还让我迷惑，那就是“架构”。

抽象概念的学习总是反复的过程

　　学习就是一个反复的过程（不知道－知道－不知道…)，对架构的理解也是。以前知识很少，压根就不能理解什么是架构，经过5年左右工作后以为自己懂了，但随着继续的深入，又发现自己还不了解。为了让自己对架构有个清晰的认识，后续我将会对架构进行一些思考，重新认识一下架构是什么，并会以blog进行总结分享，感兴趣的也可以关注一下。之前对产品线架构写过一篇《软件产品线工程方法 － BAPO之架构（Architecture）》，本篇我主要对架构的基本定义进行一些简单的理解。

架构定义种类繁多

　　产品BAPO中架构是很重要的一个维度，要想对产品开发有个很好的把握，那么对架构的理解也就至关重要了。本来想从一本宝典类的书籍去系统的学习架构，期望看完之后就拥有了架构能力，后来发现这个很难，因为每个人实际工作的经验、行业、理解、观点都不一样，作者的观点、关注点以及方向也都不一样。看看现在与架构相关的一些词汇就知道了，软件架构（softwarearchitectures）、系统架构（system architectures）、企业架构（enterprisearchitectures）、信息架构（Information）、应用架构（Application）、IT架构（ITarchitectures）、业务架构（Business architectures）、技术架构（Technologyarchitectures）、应用架构（Solution Architectures）、基础架构（InfrastructureArchitectures）、领域架构（DomainArchitectures），这些架构有的还存在各自的社区力量，不同架构之间可能还存在一些争斗，所以想要统一很难，而我需要做的就是先对对以上这些架构词汇所代表的知识进行学习，在掌握了基本概念之上再结合自己的实践和思考去逐步清晰架构的概念，整理出自己的理解。

架构的定义

　　在《企业应用架构模式》中认为架构定义本身很难统一，但是能够统一的内容有两点：

1. 最高层次的系统分解
2. 系统中不易改变的决定

　　越来越多的人发现，表述一个系统架构的方法不只一种，一个系统中也可能有很多种不同的架构，而且对于什么在架构上意义重大的看法也会随着系统的生命周期而变化，所以会出现上面所说的很多词汇。

　　以下为我看到的一些对架构的简单说明，可供参考：

• 架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解
• 架构通常指产品组成部分的大粒度的组成部分的设计，架构师在特定方法下，在经验和直接下进行系统、企业或者软件的分解，形成大粒度的组成元素。在《软件构架实践》中定义软件架构是系统的一个（或多个）结构，它由软件元素、元素的外部可见属性以及它们之间的关系组成。
• 架构是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案。
• 架构往往是对复杂系统的一种共性的体系抽象。
• 架构让我们能够正确、合理地理解、设计和构建复杂的系统。

我的理解

架构是蓝图，是从整体到部分的最高层次的划分

　　架构设计是声明性（declarative）的，而不考虑具体实现。架构是设计，但是设计不一定是架构。架构设计忽略元素内部的详细设计，这些元素的详细设计将由关注详细实现的设计人员来细化。

架构是关注点分离

架构是一种权衡

       

用友U9产品SOA设计架构遭技术质疑

架构可以先不做，但一定要先想

瓦萨战舰的故事

架构的选择对组织和产品会起到很大并且长期的影响，如果早期做了错误的选择，那么后期基本上不可能undo

架构是持续完善的

欢迎转载，转载请注明：转载自周金根 [ http://zhoujg.cnblogs.com/ ]