应用架构核心策略

应用架构的核心是将应用的领域和服务进行分层划分，其中主要应解决的问题是如何制定边界，划分的粒度怎样定义，怎样对应用架构进行分层。这里我们先讨论一些核心策略。

应用架构边界策略

针对应用架构的边界问题，有以下策略参考。

• 高内聚：采取统一的概念和定义，在内部的修改不会影响到其他应用，内部功能在总体上保持一致，有助于隔离和管理。
• 单一职责：各应用服务的功能单一，有助于控制范围边界，保证职责的一致和完整；各应用服务可自治，如可独立部署、升级、自我恢复等。
• 制定限界上下文：各部分相关行为控制在一个显示边界的范围内，深刻理解业务场景，挖掘业务知识，识别合理的上下文，才能合理定义服务边界。
• 避免循环依赖及双向依赖：业务组件之间的依赖是分层和单项的，循环或者双向会导致职责不清晰。
• 避免采用技术边界来划分应用服务边界：比如通过UI层、逻辑层、存储层等，这是技术角度的划分方法，不适合以业务为核心的应用划分。
• 避免与微服务、云原生技术体系的技术细节相关联：这样容易把简单业务问题复杂化。此外，避免引入过多的IT概念，如云计算平台、技术组件、编程语言、软件框架等。
• 避免与数据共享和通信模式相结合：数据共享涉及单一数据和分布式数据，而与通信模式相结合会涉及传输过程状态、网络状态等。
• 跳出“部门墙”思考：避免受限于组织结构，如系统、需求、分析、开发、运维团队等。

应用架构粒度策略

应用架构的粒度粗细需要适度，不宜过粗或过细，应该在满足业务需要、应用场景、管理幅度、扩展方式等多个因素要求的基础上，保持应用和服务的规模。针对应用架构的粒度问题，有以下策略参考。

• 确定粒度的依据：比如功能、职责、组织、需要的资源等，以及可独立部署性、灵活性和可扩展性。
• 粒度确认规则：按照职责划分大小，如果是微服务角度，有时也可以以代码量工程为参考，提高开发效率，降低代码风险。
• 组织跨越原则：建立一个不需要频繁跨越服务和组织边界就可进行修改的应用服务。
• 功能单一且完整原则：功能的原子性，有回滚或重试能力；同时是完整的，如果再继续细分，就会失去业务意义。
• 粒度复杂性可控：可以演化、版本化的接口契约，并尽可能使用异步方式来解耦业务。

应用架构分层参考

结合边界和粒度的思考，应用架构可以从多种角度进行分层，下面给出一些通用的参考。 从企业要服务对象的粒度角度，可以有如下分层。

• 企业级服务：企业对外（如与合作伙伴、供应商或者开放平台）提供的服务能力，通过标准协议进行对接。
• 应用级服务：将业务通过应用服务的形式对外暴露，将企业核心的业务逻辑封装在应用、产品、解决方案中，对外提供能力。
• 流程服务：把多个服务聚合成一个服务流程并对外提供，可以通过流程引擎或者更友好的流程编排界面来提供。
• 数据服务：基于数据相关的服务，比如多系统的服务集成、多数据源的数据聚合，实现数据的共享。
• 服务：提供有价值的、可重复运行的、规范标准的服务活动组件，尽量无状态、可复用、松耦合、可治理。
• 微服务：更细粒度的服务形态，通过微服务构建的服务，可独立开发、部署和维护，并通过标准接口进行交互。

从应用中服务用途角度，可以有如下分层。

• 应用层：应用系统，由应用组件组成。
• 应用组件服务层：应用级别的组件服务。
• 共享服务层：应用级别共享服务内容。
• 基础服务层：核心共用的底层服务内容。
• 规则服务层：用于流程规则配置的服务。
• 资源服务层：基础资源，如主数据服务模型。

从用户访问层次角度，可以有如下分层。

• 表现层：对外展示，包括前台页面和各种用户端触点。
• 应用层：应用系统，由服务层服务组成。
• 服务层：服务组件，服务化的基本单元。
• 基础设施层：包括基础设施资源配置，如数据库连接等。
• 集成层：与外界集成，如企业服务总线。