业务架构映射为应用架构

2021-11-16 From 张逸说 By 张逸
<p> 通过《多维度规划业务架构》,我们获得了由业务领域-业务组件-业务服务三个层次组成的业务架构。虽然是架构,但其本质仍然属于问题空间,其目的在于真实地探索问题空间,了解我们要解决什么样的问题。我们用到“分解”的方法,并非在解决问题,而是希望通过横向分层与纵向切分让问题空间变得更小,降低业务复杂度罢了。 p> <p> 这种分解层次体现为: p> <p> 领域驱动进行业务分解,既是对问题空间的探索,又自然地暗合确定解决方案的思路。由于有清晰的边界存在,这一做法并未混淆问题空间与解空间,却天然地搭建了一种映射方法,使得我们能够以较小成本将业务架构映射为IT架构中的应用架构p> <p> 映射体系如下图所示: p> <p> p> <p> 在图右侧所示的应用架构中,我旗帜鲜明地标记了前台、中台与后台,意味着我对应用架构的划分遵循了中台战略规划的思想。 p> <p> 我所理解的“中台”,满足以下定义p> <p> 显然,中台不是产品,也不是平台,而是一种规划体系。在企业架构的应用架构中,中台仅占据了中间代表了“能力服务层”的一部分,体现为由应用组件构成的能力中心。所谓的“能力复用战略动态规划过程”,就是在企业战略愿景的指导下,以能力复用为最终目的: p> <p> 换言之,中台不是独立的,随着时间的推移,应形成前台、中台和后台(统称为“三台”)职责之间联动;中台也不是静态不变的,同样随着时间的推移,三台的边界发生动态变化p> <p> 之所以要为应用架构建立中台,是以复用为目的,提升研发的效率和质量。能力中心的构成,使得整个企业系统架构可以打破烟囱系统天然构成的壁垒,也有利于它的快速演化,适应企业高速发展的业务需要p> <p> 中台战略体系保留了前台,主要是为了适应创新型产品的演变。前台的设计属于产品思维的范畴,因为它牵涉到快速试错的成本,没有时间和成本考虑对复用能力的沉淀,然而,对于中台已经具备的能力中心,不妨取“拿来主义”的态度,直接复用。如此既保证了快,又保证了稳。 p> <p> 在我认为的“三台”中,后台并非基础设施,它同样属于业务范畴。从Pace-Layer Architecture的角度讲,后台提供业务其区别主要在于它的变化频率更低,甚至可能几乎不变;从领域驱动设计的子领域角度讲,后台提供业务更加通用,以至于考虑购买而非自己构建的方式实现p> <p> 如果后台稳定地提供业务支撑,其收益高于维护成本,则不必一定要将其提炼为能力中心,甚至于它就是一个或多个相对独立而封闭的IT系统,对它的改造存在诸多阻力,改造成本极高,就得允许在企业IT系统生态中继续存在这样的遗留烟囱系统p> <p> 不管是前台的产品,还是中台的能力中心,抑或后台的工具或框架,其解决方案皆由应用组件构成,它由业务组件映射而得。本质上,业务组件与应用组件都是限界上下文,但前者对应的限界上下文只考虑了业务边界,后者对应的限界上下文在此基础上继续深化,分别考虑团队角度的工作边界技术角度的应用边界,进一步梳理限界上下文边界,使其与应用架构匹配。为示区分,我将其命名为“应用组件”。 p> <p> 应用组件与限界上下文也有不同之处。在领域驱动设计中,限界上下文确定的是逻辑边界,而在应用架构中,还需要确定它的物理边界。物理边界的确定是从质量属性角度考虑的,例如对可扩展性、可伸缩性、低延迟、高并发响应技术栈的限制,资源独立性的要求,可以确定该应用组件究竟应定义服务(Service),还是库(library)。 p> <p> 通常,中台能力中心的应用组件应考虑微服务化,后台工具或框架则不然,大多数时候,定义为库可能更合适。对于前台,可以考虑一个产品对应一个微服务,也可以考虑一个产品的特性对应一个微服务。这取决于前台产品的粒度。 p> <p> 业务架构中纯粹表达业务业务服务,在映射到应用架构时,被定义为应用组件需要公开在外的服务接口,我将其称之为“服务契约”,目的是体现服务调用者与服务提供者之间的一种”契约“关系。 p> <p> 一个业务服务映射到解空间,会定义一个服务契约;反之,一个服务契约却未必对应问题空间业务服务——因为业务服务中的一个执行步骤可能映射为一个服务契约。应用组件之间存在协作关系,根据业务服务定义,如果一个业务服务的某个执行步骤由另外一个应用组件提供,就需要将其定义为另一个服务契约,但它并非业务服务。例如,“提交订单业务服务对应于订单应用组件,需要对外公开”提交订单“的服务契约;在执行提交订单流程时,需要验证库存,该功能由库存应用组件承担。由于订单应用组件会调用它,因而需要对外公开”验证库存“的服务契约,但”验证库存“并非一个业务服务,如下图所示: p> <p> p> <p> 业务服务属于问题空间的范畴,服务契约属于解空间的范畴,如此才是合理的。 p> <p> 服务契约对应于我提出的《菱形对称架构》中的北向网关。若应用组件为服务,则对应远程服务;为库,则对应本地服务。它们都不属于领域层的内容业务服务需求表现为业务服务规约,它的输入成为领域分析建模的基础;服务契约需要构成菱形对称架构角色构造型共同协作完成,利用服务驱动设计可以驱动领域设计模型,进而对其进行建模实现p> <p>产品/能力中心/工具/框架到应用组件,再从应用组件到服务契约,都有领域驱动设计的对应模式方法实现,由此就能实现应用架构的真正落地。若按照中台战略思想规划应用架构,意味着中台的落地也有了可供参考的实现过程方法。当然,通常所谓的”中台“,都会建立双中台,即业务中台和数据中台。这里参考了领域驱动设计方法,针对的是业务中台的落地,亦可以理解为是应用架构的微服务化。至于数据中台,它关注的是全域数据的生命周期管理数据资产的梳理与建设、全域数据分析数据智能挖掘的数据服务,其着眼点显然和业务中台有着天壤之别,需要另外的设计方法实现手段。 p>

本文来源:张逸说,转载请注明出处!

来源地址:http://zhangyi.xyz/mapping-to-application-architecture-from-business-architecture/

发表感想

© 2016 - 2022 chengxuzhixin.com All Rights Reserved.

浙ICP备2021034854号-1    浙公网安备 33011002016107号