摘要：今天我接着跟大家聊一下,对于开发人员从传统的软件开发工作转到软件架构设计的时候一些关键思维的转变,包括我们常说的对于软件架构设计工作,它的一些核心工作要素有哪一些内容。

Hello，大家好。我是人月聊IT。

今天我接着跟大家聊一下,对于开发人员从传统的软件开发工作转到软件架构设计的时候一些关键思维的转变,包括我们常说的对于软件架构设计工作,它的一些核心工作要素有哪一些内容。

在前面我写过的文章或分享过的视频都专门谈到过一个标准的软件架构设计应该包括哪些内容。但是常规来说,我们很多开发人员往往就是把能够使用微服务开发架构,能够搭一个技术平台,或者是能够做一个功能模块的开发,就认为是软件架构设计的全部。那么这个理解相对来说它是相当片面的,软件架构设计更重要的就是软件思维、编程思维的一些转变。

简单来说,它的核心仍然是我们常说的,当面对一个大的问题的时候,你怎么样科学地去进行问题的定义、问题的分析、问题的解决,你怎么样去用好分解、集成、复用、组合、组装、抽象这些关键的逻辑思考要素。

因此这篇文章把软件架构设计的一些关键要点跟大家再简单的讲解一下。

比如,当我们现在面对一个大的业务应用的时候,当软件架构师拿到这个应用的时候,首先他会考虑什么东西?他一定会去考虑这个应用怎么样去分而治之,它究竟应该分解为哪一些大的业务模块或者是业务组件。

业务模块拆分

不管你用不用微服架构,你都要去考虑当你来了一个大应用以后,究竟应该分成哪一些业务模块。比如,当你做一个供应链的应用的时候,你要去考虑我需要分成招标、采购、供应商、物料这一些大的业务模块,这个就是一个关键的分解的动作,那这个分解怎么得出来的?

同样的,你首先要去梳理你的业务场景和业务流程,不管是用面向对象的方法还是结构化的方法,你首先要去做模块的分解,使之满足常说的高内聚松耦合的要求,这个是我们说的核心的在于业务架构要做的工作。

平台和框架选择

第二个工作就是我要去搭建一个完整的IT系统,我要去考虑我的底层究竟应该有一个什么样的技术文撑的平台,我应该使用什么样的开发框架、开发工具和开发语言,包括整个软件应用实现的过程中,我怎样去考虑高可用、高扩展、高可靠这一些核心的非功能性软件需求。

所以这个就是我们整个软件设计的第一个步骤,在这个步骤里面,我们可以看到,在底层的这一块,我们把它叫做非功能性的软件架构设计,在上层的这一块,我们把它叫做功能性的软件架构设计。

对于软件架构设计简单的划分法,它至少就应该包括功能性软件架构加非功能性软件架构。但是日常我们经常看到很多IT人员,他单纯的认为,我能够去搭一个大数据平台,或我能够搭一个微服开发框架我就是完全满足软件架构师的这个要求,这个理解是不对的。

我们去搭任何的技术框架、技术平台,首先一定这个平台是为了去满足你的业务需求、业务功能服务的,那实际你的业务功能、业务架构本身又来源于你对整个你的业务日标、业务场景和业务流程的理解。

软件架构师你不清楚业务场景,不懂业务流程,你就没办法去做业务模块的划分和拆解,你更不清楚怎么样去搭你底层的技术架构平台,去支撑核心的业务架构能力,所以这个就是软件架构师思考的第一个步骤。

在第一个步骤思考清楚了以后,我们就过渡到第二个步骤。

技术平台和技术组件选择

到了第二个步骤以后,我们可以看得到底层的开发框架、非功能性架构。我们把它演变成,首先你要去考虑你底层的I基础设施部署架构,这就是常说的laaS平台的内容,包括上层的就是你的本身的技术架构,开发框架,包括你为了满足整个软件非功能性设计要求,你要去考虑的一些非功能性架构设计。你需要引入的类似于消息安全、日志缓存等各种技术服务能力组件,这些我们通通把它叫做Paas的技术平台。

当然所有的整个技术架构、技术平台都是跟业务无关的,这是第一个点。

应用组件化拆分和集成

第二个点,对于核心的业务架构层,我们就会从业务架构演变到我们核心的叫应用的架构设计。如果在第一个阶段我们谈的还是业务模块和业务组件的话,到了应用架构设计,我们谈的一定是叫应用组件或者是微服务组件。

到了应用架构设计以后,我们拆分出相应的应用组件以后,这个事情还没有完,我们同时就要去考虑我们拆分出来的类似于ABCD各个应用组件之间,它们应该怎么样去集成它们之间的集成关系,它们之间相应的交互接口究竟是什么样的,所以说集成这个事情就会对应到我们说的架构里面的叫集成架构设计。

集成架构设计里面组件之间的接口怎么出来的?

同样,组件之间的接口是因为上层的应用存在业务流程,业务流程的实现往往需要调用底层各个应用组件的能力接口进行组装和编排完成的。

所以说,你会发现完成一个端到端的业务底层的应用组件之间必须要交互和协同,这个时候自然而然就出来了接口。所以说当你把这个地方想明白以后,你可以看到前端的业务流程加功能,我们就可以把它拆解成最上面的应用层,最上面的应用展现层下面还有一个就是应用层，应用层其实是可以完全做到和前端页面展现无关的,应用层更重要的是组合底层应用组件的能力。

所以到了第二步以后,我们解决一个关键的问题。在第一步,我们解决了分解的问题。到第二步,我们解决完了分解出来的应用组件怎么样去集成,怎么样去组装满足应用,满足业务流程的这个问题。

在整个集成完以后,如果我们单独来看某一个应用组件,这个时候你会看到任何一个单独的应用组件的视角,它既会提供接口给前端的另外的应用组件用,它也会去消费其他的应用组件的接口,同时它又会去消费底层的技术平台提供的技术服务的接口,又会暴露接口给上层的前端应用界面或者是APP

所以说你可以看到任何一个应用组件,它都不是孤立的,它既有左右东西的接口和流量交互,又有纵向的南北接口的交互。对于任何一个应用组件,我们去做设计的时候,都必须把我刚才说的东西设计清楚。

到了这一步把这个设计清楚以后,对于这个应用组件本身,它的内部的运转逻辑,这个时候有可能还是一个没有把它打开的黑盒子,所以到了这一步以后还没有完成。

领域模型分析

我们要做一个完整的软件架构设计,往往就会到第三步

对于任何一个组件,比如就拿组件D来说,我还要把这个黑盒子打开,可以看到它会有Service类,会有聚合根,聚合根下面可能又有实体对象,也有值对象,它可能还有其他的聚合根。同时Service类本身还要再去跟底层的我们说的仓储去做交互,仓储再去交互DB完成最后的数据的持久化,Service再朝上面去提供相应的API的接口能力。

所以当把这个单个组件内部打开以后,你会发现整个核心的线条,对外的API接口、Service、仓储这个地方形成一个完整的整体。同时Service又起了一个重要的作用,它会对多个实体的能力进行组装会去编排多个聚合根或者是多个实体的能力进行组装,形成一个统一的粗粒度的能力,通过API的接口暴露出去给应用组件用或者是给上层用,这个时候我们就把单个的应用组件打开了,也就是细化到我们常说的DDD领域建模里面更细一级的一个内容。

所以这个时候我们可以看得到,Service在这个里面就起到很重要的一个作用。

好了,即使到了这个时候,我们看得到我在整个的领域分析、领域的建模过程中,跟我的整个软件是不是微服务架构,究竟用的是传统的SSH开发框架还是Spring MVC开发框架没有任何关系。因为这一些都是脱离你局限性的开发框架,脱离你本身的前端展现、前后端分离、前端框架的最最核心的一个应用实现的内部核心逻辑。

领域模型映射到具体开发框架

只有把这个东西考虑清楚了,你再去把它映射到具体的三层框架、五层框架就会很简单。在这个地方我们既有Service类,上次我在讲领域建模的时候,有一个朋友也专门提到我们在应用层这个地方,领域层的应用层这个地方,这个地方也会有Service类,这两类的Service它的作用不一样。注意如果是单个微服务里面的Service类,它更多的是组合组装单个微服务模块里面多个实体和多个聚合根的能力。如果是在应用层更上层的Service类,它更多的是组合和组装多个微服务暴露的API接口的能力。

所以说两者之间的能力边界区分仍然是相当清楚的。所以到了第三步,我们把单个相应的微服模块拆解到这一步以后,我们整个的软件的架构设计的核心内容就完成。

好了，今天对于整个软件架构设计的一些核心思维和核心要素的一个简单讲解就到这里。

希望对大家有所帮助。再见!

来源：肥肥世界观