目录
前言
什么是概念架构
概念架构阶段的3个步骤
初步设计
高层分割
分层式概念服务架构
Layer:逻辑层
Tier: 物理层
按通用性分层
技术堆叠
考虑非功能需求
【禅与计算机程序设计艺术:更多阅读】
胜兵先胜而后求战,败兵先站而后求胜。 -- 孙子,《孙子兵法 . 形篇》
人们常常使用战术,而忽略了战略。战略要求从大局上把握整个架构与设计......架构错误的代价非常高。 -- Stephane Faroult, 《SQL语言艺术》
架构新手和有经验的架构师的区别之一,在于是否懂得,并能有效的进行概念架构设计。作为架构新手,尤其害怕碰到自己没有做过的系统:系统较大时,一点祭出“架构 = 模块 + 接口”的发布却不太奏效,架构新手就往往乱了阵脚。
有经验的架构师不会一上来就关注与如何定义“接口”,他们在大型架构设计的早期,比较注重识别重大需求、特色需求、高风险需求(抓重点关键问题),据此来设计概念架构。
另外,概念架构设计还是投标及售后工作的有力武器。金牌售前和普通售前的一个重要区别是,能否清晰的讲解概念架构,并借此说明 “客户关系的价值如何实现、担心的问题如何解决”。
”Use Case驱动“的观点既有积极意义,也有不利影响。从积极的方面看,Use Case这种需求描述方式确实有助于分析模型,设计模型,实现模型和测试模型的建立.....但是从另一方面看,OOSE对Use Case的依赖程度超出了它的实际能力。 -- 邵伟忠, 《面向对象的系统设计》
顶级设计者在设计中并不是按部就班地采用自顶向下(或自底向上)的方法,而是着眼于权重更大的目标。这些目标通常是难点问题,设计者不能轻易地看出这些问题的解决方案。为了得到整个的设计方案,设计者必须先致力于难点的设计并消除其中的疑惑。 -- Robert L. Glass, 《软件工程的事实与谬误》
概念架构是大型系统架构设计成败的关键。
下面是宏伟的金门大桥,这么复杂的架构,桥梁架构师是怎么“开始设计”的呢?

答案是:概念架构(Conceptual Architecture)。下图展示了斜拉桥的概念架构示意图。由此图可以看出,概念架构高屋建瓴的给出高层解决方案:索塔负责承重,斜拉索吊起刚性梁。

下面,来看看软件行业(来自Dana Bredemeyer等专家)中概念架构的定义:
概念性架构界定系统的高层组件,以及它们之间的关系。概念性架构意在对系统进行适当分解,而不陷入细节。借此,可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正规约及架构图,但不涉及接口细节。(The Conceptual Architecture identifies the high-level components of the system, and the relatiooonships among them. Its purpose is to direct attention at an appropriate decomposition of the system without delving into details. Moreover, it proovides a useful vehicle for coommunicating the architecture to non-technical audiences, such as management, marketing, and users. It consists oof the Architecutre Diagram (without interface detail) and an informal component specification for each component.)
根据定义,我们注意到如下几点:
high-level components)。informal specification),并给出了高层组件之间的相互关系(Architecture Diagram)。withouot iinterface detaiil)。概念架构设计分为3个步骤:

好的开始是成功的一半。 -- 谚语
所谓鲁棒性分析时这样一种方法: 通过分析用例规约中的事件流,识别出实现用例规定的功能所需要的主要对象及其职责,形成以职责模型为主的初步设计 -- 温昱,《软件架构设计》
Conceptual Architecture阶段包含3个步骤:
复杂性是层次化的。 -- Frederick.P.Brooks,《人月神话》
分析与综合是思维方向相反的过程。一部是先分析后综合,没有分析就不能综合;没有综合的分析,也只有片面的分析。 -- 肖纪美,《梳理人、事、物的纠纷:问题分析方法》
“架构 = 模块 + 接口”的做法,其不足可概括为两点。
第一,忽视了多视图。“模块 + 接口”仅是逻辑架构设计视图的核心内容,而软件系统的架构设计还可能涉及开发视图、运行视图、物理视图、数据视图等多方面的考虑。
第二,忽略了概念架构设计。对规模较大的系统而言,都必须先根据重大风险(包含功能方面、质量方面、约束方面),有针对性的制定包括“高层分割”在内的设计决策,然后才是“模块 + 接口”一级的设计。
那么,如何对软件系统进行“高层分割”呢?这属于Conceptual Architecture阶段第2步的工作。
例子:PM系统的高层分割,采用了经典的4层架构方式。

人们常说,“分层式最流行的架构模式”。从字面上理解,这似乎意味着大家所进行的“分层”在思想层面上是一致的。但事实并非如此。在实践中,分层有不同的角度,并且互不矛盾。通常会总结为“3 + 1”流派。
Layer:逻辑层Tier:物理层逻辑层(Layer)重视职责的划分,职责之间常常是上层使用下层的关系--但是根本不关心上层和下层是否“能分布”在不同机器上。

图片来源:Layered Business Architectures: Logical Structures
Services层对下层Domain Model部分的访问,是一种跨机器的远程访问吗?答案是:不知道,也不关心。整个架构图中的箭头表示的是逻辑上服务使用关系,而对物理角度是否是跨机器的访问方式并不关心。
按Layer分层 ≠ 按Tier分层。
User Interface、Services、Domain Model和Persistent Data是通用性逐渐增加吗?(”通用性越大,所处层次就越靠下“是按通用性分层的常见方式。)答案是:无法确定那一层更通用。例如,作为最下层的Persistent Data层本来支持硬盘,但后来要支持磁盘阵列,再后来要支持SAN(存储区域网络),这都要求存Persistent Data层要有针对性的进行改变。
按Layer分层 ≠ 按通用性分层。
物理层(Tier)指”能分布“在不同机器上的软件单元,不同的物理层之间必须有跨机器访问的能力--可以通过远程调用、或通讯协议等方式。

图片来源:Oracle Application Server Containers for J2EE
关于Tier这种分层方式, 最需要强调的是,几层(Tier)架构是看”能分布“的能力,不是看”实际部署情况“。
我们常说的
Java EE应该是N-Layer的,因为从逻辑上来看,Java EE里面有表现层、业务逻辑层和数据持久层。从物理上而言,这3层可以在不同的Tier上(表现层在PC上,业务逻辑层在应用服务器上,数据持久层在数据库服务器上),也可以在一个Tier上,比如Martin说过,如果把数据库、应用服务器和浏览器都装在一台电脑上,那么3-layer就在1-tier上了。
这段话问题不小。
毕竟,”N-Tiers架构“的一大好处是可伸缩性--业务量小的时候将N个Tier都部署在同一台机器上 ,等业务量大的时候再为每个Tier单独安排一台或一组机器,这恰恰是"N-Tiers架构"的目标!所以,一个系统如果架构设计时是”4-Tiers架构“的,并且开发时也实现了这一点,那么把它们部署在同一台机器上并没有改变”4-Tiers架构“。最终,工程师的实际部署方案觉得了系统是几层(Tier)架构,这未免荒唐。
其实,总结出”3级“映射关系(而不是”两级“)就清楚了:
逻辑层
Layer-> 物理层Tier-> 一台或一组计算机
关于按Tier分层 ,再看一例:微软的Azure虚拟网络系统,很明确的进行了不同的tier的划分,各层之间必然是能以进行跨机器方式的协议互相通讯的(只不过每个Tier的部署规模比较大罢了)。

图片来源:Azure中具有Apache Cassandra的Linux多層式架構 (N-tier) 應用程式
严格来讲,按通用性分层是另一种Layer,但是,绝对有必要让它”独立门户“以引起实践者的足够重视。
按通用性分层式只:将通用性不同的部分划归不同的层,以此作为系统的总体切分方式。
一般而言,通用程度越大,所处层次就越靠下。

不同,嵌入式系统的分层架构有所不同:通用性最强的层位于中间,硬件相关的部分,以及应用特点部分分布位于下层和上层。

这种“中间通用、上下专用”的分层方式对可移植性关键的通信系统、控制系统、软件平台等情况都非常重要。
技术堆叠不是独立的架构,而是基于分层架构(或其他架构模式)提供的进一步说明。
下面这个两个架构模式都是按Tier分层,并明确了各个技术点。

图片来源:I Love the Java Jive: J2EE for Oracle Technologists

图片来源:Category Archives: Day 15. Understanding J2EE Architecture
另一个例子,基本架构模式是基于通用性分层的,也加入技术堆叠的描述。

图片来源:Java SpringMVC
架构不仅仅是系统功能需求的结果 -- Len Bass, 《软件架构实践(第二版)》
在我们当中,有不少人一厢情愿的认为:只要所开发出的系统完成了用户期待的功能,项目就算成功了,但这并不符合实际。 -- 温昱,《软件架构设计》
《软件架构设计》一书中指出,“其实任何作为复合整体的复杂事物,都有可能有架构,比如一本书”。“非功能目标的考虑”在ADMEMS方法中不是一个阶段,而是一个贯穿环节。
我们接下来讨论的重点是贯穿案例 -- PASS系统概念架构设计的第3步,考虑非功能需求。
概念架构 ≠ 理想化架构
下一篇:数据结构初级<排序>