@wshcdr 简单的来说，你可以把 Controller 里面的一些逻辑转移到一个 Application Object/Service 上。

分析一下原因，按理说每一个接口的逻辑应该是不同的，唯一的，但是不同接口之间可能也会复用到一些应用逻辑，如果这些逻辑在同一个 Controller 的不同的 Method 上（ RequestMapping ），或许可以简单的创建一个私有的方法来搞定这些复用的逻辑。

但是对于不同 Controller 需要复用的逻辑，又不适合放在普通的 Service 上，就可以创建一个 Application Object/Service 来封装了，此时的顺序变成了：

Controller -> Application Object/Service -> (Domain)Service -> Repository/DAO 。

另外再说一些题外话，大部分人应该没有这些顾虑或者思考，看不懂的略过即可：

在 DDD 的战术模式中，领域服务（ DomainService ）一般只对单个聚合进行操作，且这些操作属于该领域自己的业务逻辑，只是不适合放到单个聚合上面，最重要的一点，聚合的任何操作都保证了不变性条件。

但是某一个业务需求可能会跨聚合进行操作，又要保证事务一致，就可能会在上层再建立一个应用层，注意我这里说的应用层跟 DDD 中的应用服务（ ApplicationService ）不一样，它跨聚合操作这种行为本身就是因为模型分析得不到位。因此这种逻辑是不推荐的，因为它模糊了限界上下文之间的关系，但是从编码角度来说却是很方便的。

想一想我有好几个 Service ，然后在 Controller 里面依次调用，只需要在 Controller 方法上加一个 @Transaction 的注解就可以保证事务一致，其中任何一个 Service 失败都将回滚数据，保证数据的一致性不被破坏。但其实这是一种偷懒的做法，或者说在是规模小的时候一种取巧省事的办法。