一个控制器可以在Clean Architecture中调用多个用例交互器吗？

如何解决一个控制器可以在Clean Architecture中调用多个用例交互器吗？

我正在设计一个带有Spring后端的移动应用程序。

在我的移动应用中，我有一个随机播放按钮。当用户单击按钮时，我将从GPS获取用户的当前位置并发送请求，然后使用此位置信息为当前用户查找附近的用户。

顺便说一下，使用同一用例对用例进行混洗和过滤的唯一区别是，在混洗时，我会应用默认过滤器，例如所有年龄，所有距离等。

~~随机播放/过滤请求~~

{  
  interestedGenders: ["WOMAN"]  
  minDistance: 1,maxDistance: 100,minAge: 18,maxAge: 65,latitude: 31.4,longitude: 27.1  
}

Okey，现在我的问题是我不想实时跟踪/更新用户位置，所以我认为当用户随机播放（或过滤）时我已经具有用户位置，因此首先我要更新数据库中的用户位置，然后再使用此位置信息使用其他过滤条件（性别，年龄等）查找附近的用户

我在mongo db中有3个简单的集合（帐户，个人资料和用户位置）

~~个人资料文档（简体）~~

{  
  id: "xxx",accountId: "yyy",gender: "MAN",interestedGenders: ["WOMAN"]  
}

~~ userLocation文档~~

{  
  id: "zzz"  
  accountId: "yyy",location: {  type: "Point",coordinates: [31.4,27.1]  }  
  lastUpdated: "2020-10-10T00:59:37.154Z"  
} 

这是我使用的代码。首先，我执行更新用户位置用例。如果用户在db中没有记录，则更新位置用例创建记录，否则更新用户位置。然后我发现用户符合条件。

@ApiController
@AllArgsConstructor
public class FilterProfilesController {

    private final UpdateUserLocationUseCase updateUserLocationUseCase;
    private final FilterProfilesUseCase filterProfilesUseCase;

    @PostMapping("/profiles/filter")
    public ResponseEntity<BaseResponse> filterProfiles(@AuthenticationPrincipal AccountId accountId,@RequestBody FilterProfilesRequest request) {
        var userLocation = new Location(new Latitude(request.getLatitude()),new Longitude(request.getLongitude()));

        updateUserLocationUseCase.execute(new UpdateUserLocationUseCase.Command(accountId,userLocation),() -> {
        });
        
        // Conversions from request to value objects (simplified)
        
        var query = new FilterProfilesUseCase.Query(accountId,userLocation,interestedGenders,ageRange,distanceRange);
        var presenter = new FilterProfilesPresenter();

        filterProfilesUseCase.execute(query,presenter);

        return presenter.getViewModel();
    }
}

设计这个的最佳方法是什么？
如何解耦更新位置用例（从FilterProfilesController），但仍在过滤用例之前调用？
我应该编写自定义方面还是类似的东西？

一些问题的答案

问：为什么我没有将用户位置信息放入个人资料集合中？

A ：因为我们在用户注册时没有得到此信息。因此，位置字段将保持为空，直到用户使用随机播放或过滤器页面，并且我在mongo db中使用了地理空间查询，这样我可能会导致错误。
再加上个人资料对象已经有很多字段，我认为分开的用户位置为将来的用例提供了很大的灵活性。

解决方法

通常建议您将应用程序的“写”侧与“读”侧分开。

您希望独立扩展查询服务，因为写入与读取不成比例。对于每次写入（GPS位置），您可能需要执行10倍或100倍的查询。

在您的示例情况下，您可能会首次收到GPS位置，但允许用户使用不同的过滤器组合执行多个查询。假设您自动收集用户的GPS位置，则在两次查询之间可能不会更改。

您的应用程序的域模型通常不适合查询。通常，您将构造同一数据的多个表示形式（写侧），以迎合不同API（读侧）所需的响应格式。您可以结合使用Domain Events和Subscribers来做到这一点，甚至可以为查询端单独创建一个单独的微服务。

因此，最好将GPS Location Update用例与查询分开。结果是有两个电话，但是您得到了很大的灵活性。

因此，最好让调用者（在这种情况下，UI）先执行更新，然后再请求数据。这样做还有一个好处，就是您可以异步收集GPS更新（作为ping）来更新用户位置，而不仅仅是在用户请求数据时。