应用层在分层架构中扮演着轻量级协调者的角色，它主要负责接收来自展示层（或客户端）的请求，调用领域层（或业务层）中的服务来处理业务逻辑，最后将处理结果返回给展示层。应用层本身不包含业务逻辑，它只是一个薄层，专注于协调和流程控制。

确保应用层不成为领域逻辑容器的关键在于明确职责分离。具体做法包括：

1. 严格遵守职责分离原则：明确界定应用层的职责范围，只允许它承担协调任务，如组装参数、调用领域服务、处理异常等，而所有业务规则和逻辑实现都应保留在领域层内。

2. 使用领域服务：对于不能直接映射到实体或值对象的复杂业务操作，可以通过定义领域服务来封装这些逻辑。应用层仅需调用这些领域服务，而不需要了解内部实现细节。

3. 避免贫血模型：确保领域模型是丰富的，能够表达业务概念和规则，避免仅将领域对象设计为数据容器（贫血模型），这种做法会促使将逻辑迁移到应用层。

4. 定义清晰的服务接口：清晰定义应用层对外提供的服务接口，这些接口应该简洁明了，易于外部调用者理解。接口的设计应当以业务为中心，而非技术实现。

5. 利用领域事件：当业务操作跨领域模型时，可以采用领域事件来解耦组件间的直接依赖，应用层负责发布这些事件，而领域层负责监听并响应，从而实现松耦合。

以一个简单的订单系统为例，当用户提交订单时，应用层负责接收来自前端的请求，验证请求的有效性（确保必填信息完整等），然后调用领域层中的OrderService来创建订单。如果创建成功，应用层会返回订单编号给前端，如果不成功，则根据领域层返回的错误信息，构建合适的错误响应。

此外，订单创建成功后，领域层可能会触发一个OrderCreated的领域事件，由事件处理器负责处理与外部系统的集成，如库存扣减、邮件通知等，这样应用层只需关注核心的业务流程，而不需要涉及复杂的跨系统协调工作。