架构师的第二阶段:做(Conceptual-Architecture)

  前面说到了“准备做”的内容,本节将讲述如何“做”!人们更愿意叫它“概念架构”,因为人们都比较喜欢文艺!

  程序猿出生的人,都比较喜欢用专业的词汇来理解架构,尤其喜欢高深莫测的技术。所以,开发者更喜欢“架构 = 模块 + 接口”这一说法,主要还是因为它贴近程序猿的身份,一提到接口,大家都乐了,有了接口就可以去实现接口,有了接口就知道模块间的联系,仿佛大千世界就只有用接口才能沟通你我,才能联系彼此!

  当然,对于架构来说,接口是非常重要,但只针对于程序猿!对一个架构师来说,更重要的是统筹全局,把握大的框架,而不用太关注细节,接口嘛,可以由精明的程序猿来定。

  概念架构的核心是:架构 = 组件 + 交互

  组件:只需要关注高层组件;交互:高层组件间的关系,不应涉及接口的细节。

  概念架构的流程

  概念架构可以分三个阶段来完成。

  1.初步设计

    该阶段可以基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计,这一步并不总是需要,但是对于一个新项目来说,一定要重视此步骤。

  关于鲁棒图的介绍,可以参考本人的论文:鲁棒图

  2.高层分割

    高层分割实际上是对整个系统这个庞大的概念进行切分,可以切分为多个二级系统,或者直接切分为具体子系统。分层的手段有多种,可以按照逻辑来分Layer,也可以按照物理来分Tier,还可以按照通用性来分,总之,它不是固定的,你可  以选择一种方式,也可以多种方式并存。

    下文将分章节介绍逻辑层、物理层、通用性分层。

    在高层分割的大思路下,还得考虑一下技术性问题。可以把每一层需要用到的技术描述出来。下图给一个示例:

  该图就结合了通用性分层和技术堆叠,当然,这只是一个简要的例子,实际过程中可能会用到更多的技术和更复杂的框架。但是对于架构师来说,他可以把自己团队具备的技术都给利用上。

  3.非功能需求

    非功能需求,只要记住一个词:质量!非功能需求往往是非常的笼统的,在第一阶段的时候,也强调过。总之,在概念架构阶段需要考虑到非功能需求的限制。其实,“质量”是贯穿整个架构阶段都要考虑的,而且要趁早,越早考虑越好。产品

  都做完了再去考虑非功能性需求是悲哀的。

  本节讲述了概念架构的流程,流程里面有些需要深究的地方,如鲁棒图、逻辑层等需要在接下来的章节中详细探究。

原文地址:https://www.cnblogs.com/movezzzz/p/3335506.html