业务架构映射为应用架构
这种分解层次体现为:
- 业务领域是对目标系统之系统范围进行划分,划分依据为价值高低
- 业务组件是对业务领域的划分,划分依据在于业务相关性
- 业务服务是对业务组件的划分,划分依据在于领域模型的知识语境
领域驱动进行的业务分解,既是对问题空间的探索,又自然地暗合确定解决方案的思路。由于有清晰的边界存在,这一做法并未混淆问题空间与解空间,却天然地搭建了一种映射方法,使得我们能够以较小成本将业务架构映射为IT架构中的应用架构。
映射体系如下图所示:
在图右侧所示的应用架构中,我旗帜鲜明地标记了前台、中台与后台,意味着我对应用架构的划分遵循了中台战略规划的思想。
我所理解的“中台”,满足以下定义:
- 中台是企业数字化转型的能力复用战略规划体系
- 中台是演进式的能力复用战略动态规划过程
显然,中台不是产品,也不是平台,而是一种规划体系。在企业架构的应用架构中,中台仅占据了中间代表了“能力服务层”的一部分,体现为由应用组件构成的能力中心。所谓的“能力复用战略动态规划过程”,就是在企业战略愿景的指导下,以能力复用为最终目的:
- 对于产品服务层,通过识别变化频率与复用粒度,逐步将前台的产品特性沉淀为可复用的业务能力中心
- 对于基础服务层,通过识别企业IT资产,逐步从后台的工具与框架中提炼出可复用的业务能力中心
换言之,中台不是独立的,随着时间的推移,应形成前台、中台和后台(统称为“三台”)职责之间联动;中台也不是静态不变的,同样随着时间的推移,三台的边界发生动态变化。
之所以要为应用架构建立中台,是以复用为目的,提升研发的效率和质量。能力中心的构成,使得整个企业的系统架构可以打破烟囱系统天然构成的壁垒,也有利于它的快速演化,适应企业高速发展的业务需要。
中台战略体系保留了前台,主要是为了适应创新型产品的演变。前台的设计属于产品思维的范畴,因为它牵涉到快速试错的成本,没有时间和成本考虑对复用能力的沉淀,然而,对于中台已经具备的能力中心,不妨取“拿来主义”的态度,直接复用。如此既保证了快,又保证了稳。
在我认为的“三台”中,后台并非基础设施,它同样属于业务范畴。从Pace-Layer Architecture的角度讲,后台提供的业务其区别主要在于它的变化频率更低,甚至可能几乎不变;从领域驱动设计的子领域角度讲,后台提供的业务更加通用,以至于考虑购买而非自己构建的方式实现。
如果后台稳定地提供了业务支撑,其收益高于维护成本,则不必一定要将其提炼为能力中心,甚至于它就是一个或多个相对独立而封闭的IT系统,对它的改造存在诸多阻力,改造成本极高,就得允许在企业IT系统生态中继续存在这样的遗留烟囱系统。
不管是前台的产品,还是中台的能力中心,抑或后台的工具或框架,其解决方案皆由应用组件构成,它由业务组件映射而得。本质上,业务组件与应用组件都是限界上下文,但前者对应的限界上下文只考虑了业务边界,后者对应的限界上下文在此基础上继续深化,分别考虑团队角度的工作边界和技术角度的应用边界,进一步梳理限界上下文的边界,使其与应用架构相匹配。为示区分,我将其命名为“应用组件”。
应用组件与限界上下文也有不同之处。在领域驱动设计中,限界上下文确定的是逻辑边界,而在应用架构中,还需要确定它的物理边界。物理边界的确定是从质量属性角度考虑的,例如对可扩展性、可伸缩性、低延迟、高并发的响应,技术栈的限制,资源独立性的要求,可以确定该应用组件究竟应定义为服务(Service),还是库(library)。
通常,中台能力中心的应用组件应考虑微服务化,后台工具或框架则不然,大多数时候,定义为库可能更合适。对于前台,可以考虑一个产品对应一个微服务,也可以考虑一个产品的特性对应一个微服务。这取决于前台产品的粒度。
业务架构中纯粹表达业务的业务服务,在映射到应用架构时,被定义为应用组件需要公开在外的服务接口,我将其称之为“服务契约”,目的是体现服务调用者与服务提供者之间的一种”契约“关系。
一个业务服务映射到解空间,会定义一个服务契约;反之,一个服务契约却未必对应问题空间的业务服务——因为业务服务中的一个执行步骤也可能映射为一个服务契约。应用组件之间存在协作关系,根据业务服务的定义,如果一个业务服务的某个执行步骤由另外一个应用组件提供,就需要将其定义为另一个服务契约,但它并非业务服务。例如,“提交订单”业务服务对应于订单应用组件,需要对外公开”提交订单“的服务契约;在执行提交订单的流程时,需要验证库存,该功能由库存应用组件承担。由于订单应用组件会调用它,因而需要对外公开”验证库存“的服务契约,但”验证库存“并非一个业务服务,如下图所示:
业务服务属于问题空间的范畴,服务契约属于解空间的范畴,如此才是合理的。
服务契约对应于我提出的《菱形对称架构》中的北向网关。若应用组件为服务,则对应远程服务;为库,则对应本地服务。它们都不属于领域层的内容。业务服务的需求表现为业务服务规约,它的输入成为领域分析建模的基础;服务契约需要构成菱形对称架构的角色构造型共同协作完成,利用服务驱动设计可以驱动出领域设计模型,进而对其进行建模实现。
从产品/能力中心/工具/框架到应用组件,再从应用组件到服务契约,都有领域驱动设计的对应模式或方法去实现,由此就能实现应用架构的真正落地。若按照中台战略思想规划应用架构,意味着中台的落地也有了可供参考的实现过程与方法。
当然,通常所谓的”中台“,都会建立双中台,即业务中台和数据中台。这里参考了领域驱动设计的方法,针对的是业务中台的落地,亦可以理解为是应用架构的微服务化。至于数据中台,它关注的是全域数据的生命周期管理、数据资产的梳理与建设、全域数据分析与数据智能挖掘的数据服务,其着眼点显然和业务中台有着天壤之别,需要另外的设计方法与实现手段。
相关文章
- USB应用实战视频教程第1期:手把手轻松玩转USB Host外挂扫描枪
- resnet是卷积神经网络吗_神经网络架构搜索的应用
- 单体应用、SOA架构、微服务架构的对比
- iOS应用构建与部署小结
- 【错误记录】NDK 报错 java.lang.UnsatisfiedLinkError 的一种处理方案 ( 主应用与依赖库 Module 的 CPU 架构配置不匹配导致 )
- Mac精品软件-Bartender 4 菜单栏应用管理工具 中文版下载
- AIGC 企业落地应用,尽在 ArchSummit 全球架构师峰会
- 浅析EasyCVR视频流媒体平台基于B/S架构的技术特点与能力应用
- 架构Redis Cluster在HZ中的优化应用(redishz)
- Linux应用开发:让技术潜能得以发挥(linux的应用开发)
- 系统强大的Linux:架构、分支系统与应用(linux的分支)
- SUSE 为云原生、容器化应用提供多模架构平台,助力企业 IT 转型
- 甲骨文公司的Oracle数据库,数据库管理和应用程序开发的首选。(甲骨文oracle数据库)
- PHP MySQL 构筑强大的Web应用.(phpmysql架构)
- nc命令在Linux环境中的应用(nclinux)
- 移卡与华为达成深度合作,共同打造基于鲲鹏底座的数字应用产品体系
- 架构下 MySQL 的复制MySQL 在互为主从架构中的复制应用(mysql 互为主从)
- php与mssql实战:从简单到复杂的应用 (php和mssql实例)
- 期JavaMySQL架构下的长期应用及优势(mysqljava长)
- 微服务架构下Redis四种应用模式(微服务redis四种模式)
- 构建高效数据处理系统基于Redis的应用接入(应用接入Redis)
- 构建高性能应用基于Redis架构(架构 redis)
- Oracle中JTA的架构与应用(oracle中的jta)
- Redis集群架构及其落地应用(redis集群原理及使用)
- 利用Redis集中集群架构拓展更大的应用场景(redis集中集群方式)
- umOracle数据库中ROWNUM的应用(oracle rown)
- Oracle httpd 架构打造高效优质的 Web 应用体验(oracle httpd)