欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

如何建立架构师的立体化思维?【1】

程序员文章站 2022-06-25 08:38:01
从程序员往架构师转型的路上,蔡学镛老师总结的“四维架构设计方法论”对我颇有帮助,让我对架构设计有了更加立体化、系统化的认知,现将学习心得分享出来给需要的小伙伴参考。这套方法论通过空间(X、Y、Z)三个维度及时间T维度将问题域解构成可以轻松应对的小方块,分而治之。同时,空间(X、Y、Z)三个维度联动,... ......

从程序员往架构师转型的路上,蔡学镛老师总结的“四维架构设计方法论”对我颇有帮助,让我对架构设计有了更立体化、系统化的认知,现将学习心得分享出来供需要的小伙伴参考。

这套方法论通过空间(xyz)三个维度及时间t维度将问题域解构成可以轻松应对的小方块,分而治之。同时,空间(xyz)三个维度联动,专门为单个维度解决不了的问题提供解决方案。时间 维度将问题分解到一个时间范围内,分步骤按节奏逐一解决。多维度、立体化、分层次、动态演进,这是我对这套方法论特点的总结。接下来,让我们进入这个四维的架构时空一探究竟!

如何建立架构师的立体化思维?【1】

 

 

1 四维座标系统

前后端维度(x1 … x7

前后端维度被分解为交互、业务、领域、资源四大层,其中业务可以细分为应用x2、框架x3,领域可以细分为服务x4、核心x5,资源也可以细分为代理x6、数据x7,共分为七个层次。服务x4可以实现api,如果公开,就是开放接口,调用服务层的接口,通常需要授权。代理x6可以实现spi,隔离耦合,避免核心x5 依赖特定的外部系统或数据库。每个层次做到高内聚,层与层之间做到低耦合。

如何建立架构师的立体化思维?【1】

2 x轴分层结构

在系统实现过程中,可以综合考虑现状,x2应用和x3框架可以不分拆,x4服务和x5核心可以不分拆,待后续时机成熟可以再重构分层,这样变更范围仅在内部。

2 x轴七层架构模型及其定位

分层类型

分层名称

颜色

代号

分层定位

交互

界面层

x1

界面更像是用户的延伸,而非应用的延伸。界面可被视为用户代理。根据用户喜好、语言、平台(手机、电脑、平板等)开发各种用户界面。

业务

应用层

x2

一个应用可以有多个界面,根据市场需求,开发各种应用,并以接口的方式展现。

框架层

x3

将常用的应用流程设计成框架,后续开发同类型应用时,只要通过参数或者 dsl,就可以轻易订制应用,减少开发成本。框架也可以用接口的方式开放让外部调用。

领域

服务层

绿

x4

服务层针对领域对象进行操作,并提供弹性的调用接口。服务层接口通常数目不多,但每个接口通常参数相当多。服务层没有状态,也不做缓存。

核心层

x5

核心层反映领域模型,核心层的接口基本就是对此领域模型进行操作。建立领域模型,一方面帮助接口设计,另外一方面帮助数据存储设计,梳理出弹性的存储方式。

资源

代理层

x6

具备下列作用:数据代理,代表外部系统或数据库;缓存,为了效率或提高可用性(当外部系统掉线);数据模块,支持读写分离;转接或转发,转接到外部系统,转发到日志系统;数据备份系统(通过事件钩子);热备系统接入。

数据层

x7

数据是公司最重要的资产。根据数据的特性,数据库可以是:关系式数据库;列数据库;associative dbkey-value;文件数据库;日志。

 

业务维度(y1 ... yn

从业务维度进行划分,按照业务类型对系统进行分类。业务系统的划分更多依赖业务领域的知识,这个维度设计最常用的方法论就是领域驱动设计ddd。

y轴的一个业务系统需要调用y轴的另外一个业务系统时,兼顾效率和耦合,这套架构设计方法论给出了具体的架构原则:

  1. 当被调用的是公共系统时,那么调用将被视为内部调用,即服务可以直接调用服务。考虑到公共系统比较稳定,不会经常改变,直接调用可以减少调用环节,保障效率。
  2. 当被调用的是非公共系统时,那么调用将会被视为外部调用,即通过代理层去调用被调用系统的对外服务接口。这相当于把两个系统后台进行了串联,降低了系统之间的耦合,后续被调用系统发生变更,对调用系统的影响也可以藉由其代理层进行了隔离。

如何建立架构师的立体化思维?【1】

 

3 y轴不同业务系统之间调用关系 

系统维度(z1...zn

该维度主要关注软件、容器、运行时、操作系统、虚拟机、到硬件等这些与业务无关系统的架构。z轴的系统可以分别用于前端优化、应用优化、平台优化、资源优化等层面。

如何建立架构师的立体化思维?【1】

4 z轴分层结构

时间维度(t1 … tn

对于一个新产品来说,架构不是一次成型的,从初始到成熟要经过一个不断演进的过程。对于一个已有产品来说,架构的优化也是要结合实际情况分步骤实施。

除了技术上的考虑之外,我们还需要考虑市场及投资等方面的情况。通常,在研发的初期,产品本身的定位还不太清晰,需要快速地迭代投放市场获取先发优势,以及验证想法,不断地明确产品的定位。这个阶段产品需求变动非常频繁,许多架构的驱动因素尚未明确,如果过于关注架构,那产品推向市场就会遥遥无期。随着产品定位的逐步清晰,架构的驱动因素及约束条件都逐渐浮出水面,这个时候架构设计的重要性就显现出来了。另外,我们还需要根据投资预算来调整架构设计。如果投入比较充裕,那我们就可以投入更多的人力来提前将架构驱动因素研究清楚,甚至可以针对不确定的约束提供多套备选方案。

今天先分享到这里,后续我还会继续分享各个维度的架构设计心得,请感兴趣的小伙伴记得关注哦!坚持原创写作不易,如果你觉得有价值,麻烦动动手指点个 「」,老兵哥会更有动力坚持。另外,我还会持续分享职业规划、应聘面试、技能提升、影响力打造等经验,关注 「 it老兵哥 」,赋能程序人生!

如何建立架构师的立体化思维?【1】

近期文章索引: