1 组件状态简介

本文介绍在web服务中各组件的状态分析，在框架实现的管理系统中，各组件的 有状态性 和 无状态性 可根据其是否持有用户会话、业务状态或持久数据来判断。

• 1 有状态组件

有状态组件是指组件会保存数据或状态，供后续操作或请求访问。它们通常维护一定的上下文或依赖，能够影响其后续行为。

有状态组件分析

实体类（Expense）

状态性：有状态。每个 Expense 对象持有业务数据（如金额、类别、备注等），表示领域内的持久状态。
原因：它包含业务领域的具体数据，生命周期超出单个请求。

基础设施层的存储库（InMemoryExpenseRepository）

状态性：有状态。它保存了所有的持久化数据。
原因：存储库中维护记录，代表数据存储的状态。

消息处理器（ExpenseMessageProcessor）

状态性：有状态。虽然消息处理器本身是无状态的，但它依赖于存储库来保存数据。
原因：通过存储库的有状态性，将消息处理结果保存为持久状态。

• 2. 无状态组件

无状态组件是指组件在完成请求后，不保留任何状态或上下文信息。这些组件的行为仅依赖于输入，不依赖于之前的操作或数据。

无状态组件分析

应用层服务（ExpenseAppService）

状态性：无状态。每次请求都会生成一个新实例，它只协调调用领域层逻辑，并不保存业务状态。
原因：仅作为请求的任务协调器，不维护跨请求的数据。

控制器（ExpenseHandler）

状态性：无状态。它负责接收请求并调用应用层服务，直接返回结果。
原因：控制器不保存任何会话信息，仅处理输入和输出。

领域服务（如ExpenseReportService）

状态性：无状态。它实现业务逻辑，但不保存任何跨请求状态。
原因：领域服务的所有数据由参数传入，并通过返回值提供结果。

2 状态性对比表

   组件						有状态性	 原因

  实体类(Expense)				有状态	   持有业务数据（金额、类别、备注等），
  											表示领域内持久状态。
  存储库 (ExpenseRepository)	有状态		持有所有费用记录的持久化数据。
  消息处理器 				有状态		通过依赖存储库将消息数据存储为持久状态。
  应用层服务 				无状态		每次请求生成新实例，不保存任何跨请求的数据。
  控制器  					 无状态		仅处理输入输出，不维护会话或业务数据。
  领域服务 					无状态		接收参数并计算结果，不保存状态，结果直接返回。

3 小结

有状态和无状态的设计影响

无状态组件的优势：

易于并发处理，因为没有状态竞争。
容易扩展和部署，组件之间低耦合。
便于单元测试，因为行为完全由输入参数决定。

有状态组件的优势：

表示业务模型，维护持久数据。
必不可少的持久化支持，保证系统的功能完整性。
在这个架构中，大部分组件（如控制器、应用层服务）都是无状态的，确保系统在高并发环境下的性能和扩展性。
而领域模型和存储库的有状态性，保障了系统核心业务逻辑的持久性和一致性。