02.应用服务设计

应用架构设计通常包括以下步骤：

• 根据业务架构，将业务需求转化为IT系统，识别核心应用服务。
• 划分应用结构，设计应用结构与业务流程、数据之间的关系。
• 设计应用结构之间的交互和集成关系。

本文主要分享一下应用服务、应用结构设计设计。

应用服务设计

应用服务的概念

应用服务是对一个或一组密切相关的业务对象及其操作的封装。

应用服务应明确定义其责任范围，将相关业务功能和对象组合在一起，避免暴露内部细节。它需要整合因同一原因变化的功能和数据，同时分离因不同原因变化的部分。这种设计方法确保了服务的内聚性和灵活性。

应用服务的概念源于SOA和微服务架构的兴起，通过将系统功能拆分为多个独立的服务，可以提高系统的可维护性、可扩展性和灵活性。

应用服务如何划分？

应用服务在应用架构中起着至关重要的作用，它将系统的核心功能”打包“，并提供给外部的业务流程使用，可以视为SaaS系统对外的“门面”。

用户或其他系统通过调用应用服务来实现特定的业务功能。那么，如何设计应用服务呢？

1、对齐业务能力，设计颗粒度适中的服务，职责单一，避免跨服务调用。

在设计应用服务的粒度时，可以参考领域驱动设计（DDD）中的"限界上下文"概念。业务对象类似于限界上下文中的聚合根，是应用服务的核心。

通常情况下，每个业务能力都对应一到多个独立的应用服务，同时每个应用服务也支持特定的业务能力。如图所示。

如果一个应用服务支撑了过多的业务能力，需要评估其内部是否关联了过多的业务对象。在这种情况下，可以考虑对多个业务对象进行分组，从而将该应用服务拆分为多个更小、更专注的服务。

2、围绕业务对象，提供具体的业务功能，具有明确的业务含义，不能包含不相关的功能。

从外部视角看来，应用服务通常是带有明确的业务含义，一般围绕某一个或一组密切相关的业务对象业务对象操作，不应该包含不相关的业务功能。

例如，”商城交易服务”专注于订单确认、下单和支付等功能，不应处理用户认证、商品推荐等其他业务。

3、服务可注册、可监控、可度量

应用服务的公共 API 应注册到 API 管理平台，形成一份服务列表，供消费者订阅调用。

应用服务对外提供服务时候，应能监控其运行状态，并支持启停操作。同时，服务应可度量，包括订阅数量、调用次数、响应时间等指标。

服务化架构的价值

面向服务的架构最大的价值就在于它的敏捷性和灵活性。

敏捷性体现在服务可以快速调整，独立演化。

灵活性则体现在每个服务都有清晰的业务边界，功能内聚性强，能够单独管理生命周期。具体来说：

1. 轻量级应用：采用基于服务设计的轻应用，各个服务独立开发、部署和运营，可以独立交付，影响范围小，提升交付效率。
2. 服务复用、灵活编排：通过服务的复用，柔性编排，可以快速响应业务的变化，支持复杂的业务流程。
3. 局部扩展性高：系统被拆分为独立服务后，易于横向扩展，只需扩展必要的部分，成本更低，效果更好。

示例：订单履约能力的应用服务划分

如图所示，订单履约能力是零售企业业务能力地图中的 L2 业务能力。订单履约能力可以细分为多个末级业务能力：ToC 履约服务、订单派单、订单管理、拣货管理、发货管理和履约逆向。

基于这些末级业务能力，我们可以设计出相应的应用服务。