现代企业架构框架:
https://mp.weixin.qq.com/s/SlrEu0_t0slijrNZ6DP4Ng
业务架构:
https://mp.weixin.qq.com/s/zQCjiHuxFvAg5QiOAuLAcQ
应用架构的核心关注点是业务需求是由哪些应用承载的,它们与用户是如何交互的,它们之间的关系以及是如何交互的,它们访问或变更了什么数据。
应用架构的设计主要以应用(Application)的设计为核心,向外围可以延伸到平台型企业架构对于应用分层,分组的设计。例如大家关注的以微服务为代表的分布式应用架构,以及此类架构模式下的常见问题,例如微服务如何划分如何组织,都是应用架构在这个粒度需要关注的问题。
同样,以应用为基准,向内部延伸又会涉及到应用内部的架构设计。例如常见的应用分层设计,领域驱动设计中提到的六边形架构、洋葱模型,包括领域对象的详细建模与设计,都是在应用架构这个粒度需要关注的问题。
而其中的领域对象设计在业务架构以及后续的数据架构中都会提及,本框架充分融合了企业架构与领域驱动设计的思想和方法,从业务架构到应用架构以及后续展开的数据架构,都秉承以领域对象设计作为架构的核心要素,跨越架构边界,使领域对象作为一条主线,串联起各个架构视图,也有利于保证各类架构的连贯和一致性。
应用架构的内容元模型包括“端口”、“结构”、“状态”三个部分,如下图所示:
结构部分用来对 IT系统的职责、边界建模,其中包括,应用组件、应用、应用组、应用层
端口部分用来对应用的出入口建模,其中包括应用服务和扩展点
状态部分用来对应用状态的变更建模,其中包括领域对象和不变量
平台化趋势意味着企业 IT 系统的形态逐渐从扁平结构转向分层结构,即一部分应用提供可复用的能力, 组成底部的平台,而其他应用建立在平台之上。
除了能力复用外,另一个提升 IT 支撑响应力的关键是,提升 IT 系统各组成部分的自治性,使得变更能够相对独立的、以小步快跑的方式发生。因为无论是创新也好,集中管控也好,虽然变化速率不同,但变化始终存在,既然变化不可避免,我们应将精力投入到应对变化上。
在我们的经验中,应用边界划分不合理会对应对变化产生明显的负面作用:
这些负面作用会拖慢 IT 支撑的响应力或稳定性,因此,“如何划分 IT 系统的边界,以合理的布局更好地应对变化”是需要解决的挑战。在平台化趋势之前就已经开始流行的微服务架构风格的催化下,这个挑战就已凸显,而平台化强调可复用的服务,必然会对原有系统进行打散和重组,进一步加剧了这个挑战。
从上文的分析可以看出,边界划分其实从应用架构视角出发,对功能、运行层面变化的应对设计,是应用架构设计的重要部分。我们在进行应用架构设计的过程中,融合了领域驱动设计中的限界上下文与统一语言的概念,延续业务架构部分中对于领域对象的识别和子域划分,结合组织与技术的要素, 从多个方面充分考量对于应用的建模。
汽车行业的经销商,会同时开展新车销售和售后服务两个不同的业务,在经销商内部一般也由不同的组织负责。
而维修保养和配件销售又是售后服务中的两个不同业务场景。
我们可依此快速建立一个两级的应用组, 这个结构并不精确,但足够我们进行下一步工作。
按职责类型分解,应用组件可分为四种常见的参考类型
企业有多条业务线,各自有不同商品结构, 原各设置一个前台团队负责其应用的交付和运营。
为降低成本,决定将各业务线的商品展示、搜索等需求集中起来,设立商品中心作为平台支撑层的应用 / 应用组。
这个初衷是好的,但如果商品中心仅仅是“复刻”各业务线的商品结构,而未作相应设计的话,面对多条业务线的多线需求,往往不堪重负,成为瓶颈。
在线上订餐流程中,用户需要 IT系统支持提交订单、发起付款、订单状态查看、取消订单四个行为,可将它们建模为应用服务―― 订餐结账
总结来说,应用服务和扩展点是对边界概念的加强, 帮助我们理解跨边界的交互。
我们建议将边界划分的结果及过程依据保存下来并可以开放给授权人员访问。这是因为我们常常见到这样的问题:“新的功能应该放在哪个应用实现?”
这个问题背后的原因可能是应用的边界划分不清晰,职责模糊,或者是边界划分的结果及依据丢失了。常见的现象是我们看到一张张应用架构全景图,由若干个方框组成,代表一个应用或应用组件。由于缺少上下文,仅凭方框内的名字很难判断应用的职责范围,所以不好回答“新的功能应该放在哪个应用实现”这样的问题。
解决这个问题的难点是如何简练、清晰地描述应用的边界和职责。在全景图的基础上,为每个应用 / 应用组件增加职责描述是一个不错的起点,但仅用文字描述可能存在歧义。我们建议通过建立应用架构与业务架构、数据架构的构建块映射来解决这个问题。
通过构建块映射关系(业务流程使用应用服务,应用服务由应用组件提供,应用组件操作数据对象), 应用 / 应用组件在业务活动中的职责有了明确的表达,再配合文字来描述引导阅读和理解,效果更佳。我们推荐为每个应用组 / 应用 / 应用组件建立自己的主页,将其与其他元素的映射关系作为内容显示地展示出来
最后,应用架构阶段更像是在为 IT 系统应该建设成什么样子提出要求,所以应用架构设计应该是和技术实现方案解耦的(虽然技术的升级可能使得应用架构的设计风格产生变化),从而将技术变化隔离在可控范围内
原文: ThoughtWorks发布《现代企业架构白皮书》 (qq.com)