架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。为了对架构有更加深刻的理解和掌握如何进行架构,我阅读了《架构之美》这本书。这本书是来介绍系统的设计方法的。
首先对架构的基本概念进行了了解。在建筑,音乐,写作等各种行业都可以看到这个词的出现.架构是系统设计的一部分,它突出了某些细节,并通过抽象省略掉了另一些细节。软件系统的架构包括行为上的和结构上的。外部行为描述展示了软件如何与用户、其他设备和外部设备进行交互,也就是需求。结构描述展示了软件如何被划分为多个部分,以及这些部分的关系。
架构是系统设计的一部分,架构设计关注的侧重于组件的内部结构。架构的设计受到许多因素的制约,架构是好是坏并没有统一的标准。这取决于人们对软件的需求、软件被构建和运行的环境,以及软件团队本身的特点等等因素。评价软件好坏有很多指标,例如性能、安全、可伸展性等等。一般来说,这些指标是很难全部满足的,试图改进其中一个往往会对其他指标产生负面影响。所以从某种意义上来说,软件架构是折中的游戏。对于一组功能需求和品质需求,没有唯一的正确架构。
好的架构展示了架构完整性,减少复杂性,指导详细设计和系统验证。待构建的系统需要具备几点要求:具备客户要求的功能;能够在工期内安全的构造;性能好;可靠;可用;安全;成本适度;符合法规;超越竞争者/前人。因为没有一个系统能够同时满足所有要求,所以架构是一种折中,挑出最为重要的几点来实现。
软件系统就像是一座由建筑和后面的路构成的城市,本书使用抽象的例子两个软件城市生动的介绍了软件系统应处于哪种生存模式中。一个是“混乱的大都市”。并没有一套健康的架构,通过整个系统的阅读并不能清楚的各个之间的联系。这将带来一系列的后果。第一:导致这将成为一个很难让人理解的系统,这将几乎不可能修改。新加入项目的成员将不能理解系统。坏的架构设计又继续会招致更坏的架构。第二:缺乏内聚。每个组件本来应该有一个良好的角色,但是它们却包含了一堆杂乱的、不一定相关的功能。这很难弄清楚系统已经实现了哪些具体的功能。第三:代码的问题以及代码以外的问题。“大都市”的问题随着时间的推移问题将逐渐变的严重不可修复。从这里清楚的看到缺乏健康的架构的严重性。另一个则是与之相反的“涉及之城”与其最大的差异在于具有健康的架构。
通过这两者的比较来讲,我明白架构在软件中的重要地位。软件架构对新产品开发、产品线开发、软件维护以及软件升级都有很重要的作用。是沟通现实世界和计算机世界的一座桥。