我的架构思想(十二):你所关注的系统——知识的构建(“识别架构意图”的核心理论与方法)

阅读数:23 2019 年 10 月 12 日 16:52

我的架构思想(十二):你所关注的系统——知识的构建(“识别架构意图”的核心理论与方法)

那么,架构意图到底是什么呢?

架构意图需承架构的定义而来,它首先必是“经营角色对方向的设定”在系统上的体现。若架构意图不体现方向,则它将只是局部的、边角的一些架构决策12或意图13。架构师的核心价值,在于通过架构意图来将“方向设定”映射为“规模与细节”。其中,“规模”表现为架构的边界 / 范围,“细节”表现为架构部件的联接关系 / 联接件。

12 架构决策是下一章要讨论的问题,但许多时候架构决策被混用为我们这里讨论的架构意图。

13 这里的“意图”是指某些与架构无关的意图,或阶段目标的架构意图。

对于架构意图的识别,有三个入手的角度。这三个角度仍是“规模与细节”相关的,其一,是系统的脉络;其二,是系统的组织14;其三,是系统组织间的关系。如果一个意图表现了架构师对系统上述三个方面的理解,则该意图应当视为架构意图15

14 组织在这里是有两层含义的:其一,它作为名词以表明组成部件;其二,它作为动词以表明部件之间的结构过程

15 意图并不一定是“单纯”的。架构意图可能同时蕴含了架构师在其他方面(如公司政治、市场决策等)的考量,但我们这里只讨论其在外在表现上能否作为在系统架构与设计中一以贯之的架构意图,而忽视了其他方面。

第一个方面,系统的脉络是对方向性的体现。这包括系统内在的动律与整体的动向两个方面。前者,即内在动律意味着架构师应当对系统(作为一个整体)的核心运作规律加以考察,这包括一般过程、限制条件以及最基本的系统要素间的流转关系。下面以支付系统为例。

  • 一般过程:在某种支付场景下,用户 A 与用户 B 之间的一次资金转移。
  • 限制条件:支付场景、用户 A、用户 B、资金以及资金的转移这五个因素是否被“当前系统”所理解。如果不理解支付场景,则应该将上述过程实现为流水,反之可以实现为一笔交易或基于订单的支付过程;如果不理解用户 A 或用户 B,则应该将上述过程置于一个会话或在过程中使用 token/ticket 以识别16,反之支付过程应当自行决定是否需要对用户进行复核(例如站内消息或手机短信通知与验证);如果当前系统不理解资金转移,则应当记录支付行为并提供外部查询接口,反之则可以完成资金转移。

16 token 与 ticket 是常用的系统外认证的技术。这意味着具有某个认证系统专门来验证用户 A 或用户 B 的真实性,并在系统间将一个或一组识别用的凭据 token/ticket 传递给当前系统与用户,以使当前系统能够可靠地识别用户。

  • 流转关系17:其一,用户 A 与用户 B 之间的消息通信(可选);其二,系统与用户 A、用户 B 的消息通信,例如短信确认与通知等;其三,用户 A 与用户 B 的资金账户中的资金变化。

17 一个完整的支付行为涉及资金流与信息流,后者主要用于保障一个支付行为的可靠性。当考虑用户间的信息流转时,它可能是一个用户授信的支付系统;当考虑系统与用户的信息流转时,是在支付过程内加入了安全需求。

后者,即整体动向意味着架构师应当对系统的长期目标做出考量,这包括18:系统是独立系统还是公开系统,是规模渐增还是功能渐增的系统,是战略上的布局还是战术上的一个实现点。以金融业务中的清算系统为例19,它通常是一个独立系统,因而不需要公共接口;它会随业务量的增加而规模渐增,但不会在系统功能上有明显变化;它通常只是一个关键技术点,而不会影响到整个金融业务的战略构画。

18 这里只是列举了三个设问,它们事实上分别反映的是系统的三个方面的特征:依赖、复杂性与持续价值。

19 这里讨论的是内部独立清算业务,跨行(银行间)与跨系统清算等业务与此有相当大的区别。

第二个方面,系统的组织是对范围的考虑,它主要讨论将哪些内容放在一起的问题,它一方面决定组织在内含上的规模,另一方面也决定组织在外延间的距离。以上面的支付系统为例,系统中是否完整包括“支付场景、用户 A、用户 B、资金、资金的转移”这五个构件,是需要被确定的。正如上述——在第一个方面中的分析所体现的,系统的组织既决定了“限制条件”的细节,其本身也取决于对系统脉络的分析。亦或说,很难孤立地看待系统脉络与系统组织,它们是在一个完整的、整体性的思考过程中的反复权衡。这一权衡的基本依据是上述的整体动向,例如若支付系统开放20,则账户 A 和账户 B 必然要从支付过程中抽取出去,并且相关的流转关系必然依赖外部系统;若将支付过程理解为功能渐增的系统,则它必然不适宜开放,因为这意味着接口趋向于应付功能变化,进而导致接口变化——而接口频繁变化是不合理的;若它本身只是战术实现点,那么它的开放基础就将建立在技术方案(如数据架构或系统群集等)之上,难以对行业、渠道或领域构成实质性的影响。

20 这里的“开放”是指将支付系统作为一组可公开调用的服务,提供给第三方公司或其他领域中的业务过程使用。

第三个方面,组织的关系是对联接件的考虑,它主要讨论上述组织成员间的通信,并进一步决定通信的形式与其成本21。仍以上面的支付系统为例,我们假定22用户 A、用户 B 与支付场景都是外部系统,那么我们必须考虑的联接关系就包括:其一,用户 A 和用户 B 是否具有消息通信过程,如果有,应当如何实现,例如是实现为专用网络中的通信客户端,还是使用类似手机短信这样的第三方通信网络;其二,用户 A 和用户 B 与支付场景是否有关系,是否在支付场景中通信,例如站内短信、通知等;其三,这些外部系统与(当前)支付系统之间是否有通信关系,例如安装服务端通信模块,或依赖于在外部会话中建立凭据。

21 总体来说,我们是要削减通信成本的。因此,应尽量要求组织成员间无关系、不发生通信行为,或在发生通信行为时尽量不对当前系统的“一般过程”构成影响。例如,即使支付过程的确需要用户 A 和用户 B 发生一次通信来增强安全性,那么也应当尽量在支付场景中通信,而不是在资金转移中通信,亦即是将这一行为视为交易安全,而非资金安全。

22 该假定是以“需要实现为开放系统”这一动向为基础的。

架构意图中最重要的是系统的脉络,其整体动向是本质性的需求,其内在动律是上述需求的表现与表达方式23。总体来说,任何一个架构意图的形成都是对三个“入手角度”整体的反复考量进而形成的一个最终认识,而决非其单一方面的阐述。例如,以上述的支付系统来说,最终的架构意图应叙述为24

23 也许不应该如此片面地定义整体动向与内在动律的关系。究竟是整体决定内在,亦或反之,是有哲学思考的意味以及观察角度的设定的。另外,质变与量变也是脉络中的一个关键思考,例如逻辑复杂性是否会决定架构意图?

24 架构意图的叙述是简洁且毋庸置疑的。例如,此前的办公系统,在“架构 v0.0.0.2”中的架构意图就是:它是一个管理系统,而非业务系统。

一个跨领域的开放支付平台。

评论

发布