文章速览：

行业：互联网

关键字：架构

摘要： 应用架构，可以理解为一个按某种规范和约束将业务能力进行拆分，并由不同应用（系统）承接的结构载体，从而能够实现将拆分后的应用以一种规律有序的方式进行连接并创造业务活动。本文带来了一些日常应用架构分析或者决策的指导方法。

阅读时长：13分钟

 

以下文章来源于twt企业IT社区！作者：陈俊

 

【作者】陈俊，拥有金融业12年工作经验，在IT领域覆盖过运维、开发、管理、规划、产品等方面，熟悉信用卡业务领域。

 

应用架构，可以理解为一个按某种规范和约束将业务能力进行拆分，并由不同应用（系统）承接的结构载体，从而能够实现将拆分后的应用以一种规律有序的方式进行连接并创造业务活动。

你可能会听说过"六边形架构"、"洋葱架构"、"整洁架构"等应用架构思想，但这些可能更偏向于一种技术实现视角，其主要用于解决模块或组件等如何被组织的问题，从而分离业务复杂度和技术复杂度。

而应用架构更像是业务架构和技术架构之间的一种纽带，用于完成业务架构向技术架构的衔接或映射，如果用一句话来概括的话，应用架构就是向上创造业务活动的结构载体，向下指导技术实现的设计模式。

那么在日常应用架构分析或者决策中，是否可寻求一些指导方法？今天就来聊一聊应用架构设计。

 

核心理念

适度 · 简约

约束 · 边界

一致 · 动态

共享 · 高效

 

四原则

原则一：向上支撑业务架构，向下依托技术架构，在适度满足业务能力的前提下，简化技术实现难度，但需具备一定的前瞻性。

原则二：清晰明确应用间的边界及依赖关系，建立应用间的交互模式和协议契约，避免能力分散或重叠等边界不清的现象。

原则三：力争实现企业级应用架构设计的一致性，并随业务规模扩张或业务规则变化，可驱动架构持续性的动态调整。

原则四：保证应用可用性及可维护性的基础上，逐步提升应用的共享复用能力，从而提升研发效率及降低运维成本。

 

八步骤

步骤一：从企业战略层视角，梳理出用于实现战略目标所需要具备的「业务能力」，并制定相应的「业务流程」。

步骤二：分别对每个「业务流程」进行分解，形成不同的「业务节点」，并从节点中识别「业务概念」。

步骤三：分别在每个「业务节点」上，对所识别出的「业务概念」设定处理逻辑，形成不同的「处理单元」及「过程数据」。

步骤四：将关联度较高的「处理单元」及「过程数据」封装为「应用单元」，并对处理逻辑重复的「应用单元」进行去重。

步骤五：根据「业务能力」的灵活度诉求，可将不同的「应用单元」进行选择性整合，并形成「应用系统」。

步骤六：「应用系统」以暴露服务的方式，对外提供逻辑处理能力，并由「业务流程」根据需要进行编排，从而实现「业务能力」。

步骤七：可将交互频繁的「应用系统」组成「应用领域」，可对「应用系统」内部采用"六边形架构"、"洋葱架构"、"整洁架构"进行逻辑分层。

步骤八：评估上述应用视图会带来的开发及运维成本，并进行适应性微调，包括「应用单元」重组或「应用系统」间交互模式的设定。

 

总结

综上所列，应用架构设计并不是公式，更不是银弹，它是一种结构化的思路，其更重要的意义，是期望让组织中的架构设计人员，对于应用架构的认知水平能够尽量达成一致，并始终将它落实在应用架构决策上，从而形成一种公约。

而从企业架构演进的趋势来看，应用架构势必会成为连接业务架构和技术架构的重要组成部分，所以，我们应及早正视起来，并进行有效“投资”，它一定会给组织带来非常可观的价值回报。

最后，感谢近期付老师（付晓岩）的耐心传道授业解惑，让我对企业架构的理解得到了重新的认识，并逐步从技术视角转向业务视角。

 

以上是针对架构的分享，希望对大家有帮助

 

 

阅读原文

 

声明：本文章版权归原作者及原出处所有 。凡本社区注明“来源：XXX或转自：XXX”的作品均转载自其它媒体，转载目的在于传递分享更多知识，内容为作者个人观点，仅供参考，并不代表本社区赞同其观点和对其真实性负责。本社区转载的文章，我们已经尽可能的对作者和来源进行了注明，若因故疏忽，造成漏注，请及时联系我们，我们将根据著作权人的要求，立即更正或者删除有关内容。本社区拥有对此声明的最终解释权。