我同意领域驱动设计（DDD）中提到的应用服务（Application Service）应该保持无状态的观点。原因如下：

1. 提高可伸缩性：无状态服务可以更容易地进行横向扩展。服务器可以随时增加或减少，而不会影响到系统的运行状态。因为没有状态需要在不同实例之间保持同步，所以可以更加灵活地应对负载变化。

2. 简化部署和维护：无状态服务使得部署过程更加简单。无需关心服务内部的状态，每个请求都可以独立处理。这对于持续集成和持续部署（CI/CD）流程非常有利，可以更快地进行版本迭代。

3. 增强容错性：如果应用服务是无状态的，即使某个服务实例突然崩溃，也不会影响其他正在处理的请求。新的请求可以被转发到其他健康的服务实例上，从而提高系统的整体可用性。

4. 促进服务之间的解耦：无状态服务减少了服务之间直接的状态依赖，使得服务之间的交互更加清晰和独立。每个服务只需要关注自己的职责，而不是管理与其他服务之间的复杂状态。

5. 便于测试：无状态的服务更容易测试。由于每个请求都是独立的，不依赖于任何外部状态，测试时可以更加简单地验证服务的正确性。

示例：假设我们在设计一个电商平台的应用，其中有一个订单服务（Order Service）。如果订单服务是无状态的，那么每次处理订单创建请求时，服务内部不会保存任何订单的状态信息。相反，所有必要的状态信息都会从数据库或其他持久化存储中读取。例如，当用户提交订单时，订单服务会从数据库中读取用户的购物车信息、库存信息等，然后创建订单并保存到数据库中。这种方式确保了即使订单服务的实例发生变化，也不会影响到订单的处理过程。

当然，有时候业务场景可能会要求服务保持某种状态，比如会话管理。在这种情况下，可以通过引入专门的会话管理服务或者使用外部状态存储（如Redis）来处理状态问题，而应用服务本身仍然保持无状态。