我正在构建一个MVC Web应用程序（使用Spring MVC框架），但是在设计特定区域时遇到了一些困难。
该应用程序必须与一系列Web服务进行交互，这些服务的设计并不是很好，并且本身并没有提供太多抽象 - 基本上每个“数据类型”的创建/更新/检索/删除操作都有一个Web服务方法，除此之外就没有太多API了。 Web服务客户端需要知道要调用哪些方法以及以哪个顺序来创建所需的数据 - 换句话说，没有“事务”基础的方法。
例如，仅创建新用户帐户就需要调用总共七个不同的Web服务方法来设置所有必要表中的记录（一个 用户 记录，将正确的 特权 添加到该用户，设置用户的 计费 详细信息等）。
我正在努力找到最佳方法来抽象化并封装它在我们的应用程序中。大部分应用程序都遵循标准流程：
request ---> Controller <---> Service/Business-level object <---> DAOs for data access
在我的应用程序中，我使用自己的“领域对象”来表示和抽象Web服务WSDL中定义的数据类型，以便我的领域逻辑不依赖于Web服务类型，并且我们可以抽象和隐藏任何我们想要的细节。
我正在寻求一些意见，关于设计上述的“用户创建过程”的最佳方式。创建“普通用户”的过程涉及调用七个不同的Web服务，但这只是一种“类型”的用户-我们将必须能够创建几种不同类型的用户，每种类型都需要调用不同的Web服务。
目前，我只设计了这个“普通用户”创建，作为一个概念证明-我有一个领域对象“User”，一个“UserDao”接口，其中包含用于“getUser（name）”和“createUser（User）”的方法，以及一个“WebServiceUserDao”，它实现了“UserDao”方法并知道如何调用上述七个Web服务方法。“createUser()”方法由一个“UserCreationService”调用，这是我的业务/服务级别类，依次由“SignupController”调用。
但为了扩展此逻辑以能够创建不同的用户类型（由中的不同值表示），我不确定在业务/服务层类和DAO之间画出界限的位置。例如，我应该：
1. 为每个“用户类型”创建一个UserDao实现，以便可以将创建每个“用户类型”的逻辑封装在其自己的类中，并让UserCreationService决定使用哪个UserDao？这将对应于1个服务类：多个DAO。
2. 我应该将UserDao拆分成更小的部分，每个部分相应地创建Web服务/ DB中需要创建的每个“记录”，即使我的整个应用程序不需要知道每个这些单独类型之一？然后为各种不同的“用户类型”有不同的UserCreationService实现？换句话说，这种策略将具有PrivilegesDao，BillingPlanDao等，即使我不需要相应的特权或计费计划领域对象。这将是许多服务类：许多DAO。
3. 在一个WebServiceUserDao中包含所有关于每个“用户类型”需要调用哪些Web服务的逻辑？这将有一个非常复杂的类（PMD已经在抱怨圆形复杂度），但是所有这些逻辑都将封装在一个类中，从总体API角度来看，这可能导致较少的复杂性。
我在这个应用程序中的一个目标是确保如果我们需要更改数据持久性的详细信息，那么我们只需要更改DAO实现 - 如果我们必须开始与不同的计费系统进行接口，我不希望应用程序的任何部分发生变化，除了DAO级别。
有什么意见吗？当业务逻辑与数据访问逻辑似乎重叠时，您使用哪种策略来决定何时拆分它们？