我对应用程序服务的理解是它们将域和用户界面连接在一起。换句话说，它们为控制器提供服务，以便对域执行操作。
我的应用程序中有以下项目布局：
- 域核心 - 基础设施 - 服务接口 - Web UI - 视图模型 - 视图 - 控制器 - 服务（应用程序服务）
我的“服务接口”位于“Web UI”项目之外。然后在“Web UI”项目中，在“服务”下实现服务接口。
然而，这种结构有点缺陷，并且在实践中会创建循环依赖。我试图遵循此链接中的架构：https://www.develop.com/onionarchitecture 对于给定的服务，我想传入视图模型，根据视图模型对域执行操作，然后返回更新后的视图模型。这种方法是否错误？
我的应用程序中有以下项目布局：
- 域核心 - 基础设施 - 服务接口 - Web UI - 视图模型 - 视图 - 控制器 - 服务（应用程序服务）
我的“服务接口”位于“Web UI”项目之外。然后在“Web UI”项目中，在“服务”下实现服务接口。
然而，这种结构有点缺陷，并且在实践中会创建循环依赖。我试图遵循此链接中的架构：https://www.develop.com/onionarchitecture 对于给定的服务，我想传入视图模型，根据视图模型对域执行操作，然后返回更新后的视图模型。这种方法是否错误？
我的理解是应用服务本质上将视图模型作为参数，如果需要更新领域和视图模型中的一些细节，然后返回一个视图模型。
或者
应用服务只处理C#数据类型和领域模型作为参数，并返回相同的数据类型？换句话说，不会获取或设置视图模型中的任何信息。实际上，不知道视图模型的存在。
我只需要一些关于严格的DDD方法的最佳实践的澄清。