如题所述
不同的架构方法论,会将架构分为不同视图,每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系,分为以下几种视图:
1.数据架构:描述数据的存储结构、格式等方面。
2.物理架构:描述机器的物理部署、网络拓扑方面。
3.运行架构:描述运行期线程、进程间的交互工作机制。
4.逻辑架构:指如何将代码分成不同模块、组件,以及之间的职责分配、交互行为。
5.开发架构:主要指开发工具的选择,程序单元的划分,开发管理规范流程等方面。
例如分为哪些工程、项目,源代码管理,自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系,他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图,可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念,不知道是出于调侃还是无知。
埃及的金字塔、神庙的建设,不是几个平常的泥瓦匠聚在一起就能够造出来的。
像SAP、OracleERP,国内的金蝶等大规模的系统,以及空间站、火箭的控制系统等,没有系统性的架构方法、规范、流程,结果只能是悲剧。
当规模、复杂度没有达到一定程度,比如在一些小的团队、产品中,架构过程可能融入到老板、经理、组长、资历较深的一些开发者中,融入在大家的日常工作中,以至于感觉不到架构的存在。
就算遇到一些问题,因规模不大、复杂度不高,也比较容易调整。
当这些前提条件发生变化时,架构的作用和必要性就逐步的体现出来。
总的来说,一说到架构,如果懂软件,那么会了解为一个软件系统,这个软件设计的组成结构,如哪些是基础支持组件,哪些是完成A业务,哪些完成B业务但说道企业架构的时候,就会问,该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构,以及如何链接在一起。
倒觉得,一个企业确实需要这样的架构,但不要神话它,最主要的是业务如何最终体现到软件中和流程中。
而采取分离式设计时,最容易的错误就是各自为政,集成困难。
那么以数据为中心的架构设计,会自然提供集成的基础。
提到过,企业最重要的资产是数据,甚至不是信息,是数据。
企业的业务流程会变,IT系统会变,所需要的信息与知识会变,唯有数据能够积淀下来。
这有点象自然演进,考古那种,啥都