软件体系结构和软件架构是一个意思吗

软件架构:整个软件系统的各个模块之间的结构设计，是软件工程范畴的概念，就象设计一栋房子由几个什么样的板块组成一样。
软件体系结构：是软件编程风格范畴的一个通俗概念，比如说用c++、poworbuild、delphi等来进行软件设计是面向对象的编程语言体系结构，而basic、c、foxbase的软件体系结构特点是面向任务流程的（不是面向对象的编程语言）。

框架（Framework）是一个框子——指其约束性，也是一个架子——指其支撑性。

IT语境中的框架，特指为解决一个开放性问题而设计的具有一定约束性的支撑结构。在此结构上可以根据具体问题扩展、安插更多的组成部分，从而更迅速和方便地构建完整的解决问题的方案。

目前还没看到什么有趣的个人化解释，可能是因为要解决都复杂到设计出框架来解决的问题的人比大多数有情趣的人来说都更感觉boring吧，所以……嘿嘿！

互联网是个神奇的大网，软件框架也是一种模式，如果你真的想做，可以来这里，这个手技的开始数字是一八七中间的是三儿零最后的是一四二五零，按照顺序组合起来就可以找到，我想说的是，除非你想做或者了解这方面的内容，如果只是凑热闹的话，就不要来了。

也就是说：1）框架本身一般不完整到可以解决特定问题；2）框架天生就是为扩展而设计的；3）框架里面可以为后续扩展的组件提供很多辅助性、支撑性的方便易用的实用工具（utilities），也就是说框架时常配套了一些帮助解决某类问题的库（libraries）或工具（tools）。

约束性：针对解决特定问题的软件框架会首先定义问题的边界，进而将相关的软件组件约束在这个边界内，保持框架在解决问题方面上的内聚性。

支撑性：框架本身是不解决什么问题的，但给了解决问题的相关组件一个插接、组合的底子，这个底子的科学性和易用性直接影响到在此之上进行进一步开发的科学性和方便性。

框架不一定只是解决软件开发问题，也可以解决软件工程问题（比如Microsoft Solution Framework）或信息系统等问题。

不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。

比如希赛推的ADMEMS架构体系，分为以下几种视图：

1数据架构：描述数据的存储结构、格式等方面。

2物理架构：描述机器的物理部署、网络拓扑方面。

3运行架构：描述运行期线程、进程间的交互工作机制。

4逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。

5开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。

例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。

目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。

想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。

另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。

埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。

像SAP、OracleERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。

当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。

就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。

当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。

总的来说，一说到架构，如果懂软件，那么会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及如何链接在一起。

倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。

而采取分离式设计时，最容易的错误就是各自为政，集成困难。

那么以数据为中心的架构设计，会自然提供集成的基础。

提到过，企业最重要的资产是数据，甚至不是信息，是数据。

企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。

---