首先让我说 Prism 和 WCF 是互斥的框架，使用其中一个并不妨碍以任何方式使用另一个。
a) 为什么要让他们决定如何托管他们的 WCF 服务？最简单的配置是 IIS 托管，它需要最少的设置。一个 IIS Web 可以托管所有六项服务，除非您需要通过将每个服务放在单独的应用程序池中来设置内存屏障。在服务主机中运行服务就等于编写一个 EXE（例如 Windows 服务）来为客户端提供服务。更多的工作和配置（从 Windows 服务端来看，WCF 配置是相同的，除非它通过在 HTTP:80 上运行而与 IIS 冲突）。您有很多方法可供选择，但您使用的是 WCF，所以我假设您有一个客户端/服务器方案。如果您有 Windows 服务器，请使用 IIS，恕我直言。
b) 您可以在同一个服务主机中运行任意数量的 WCF 服务，但如果其中一个服务失败，整个 EXE 就会崩溃。这就是为什么我建议使用 IIS 应用程序池，它会在失败时自动重启，并且可以配置为在不同的应用程序池中运行每个服务。
c) 服务集成代码的放置位置有不同的策略，具体取决于应用程序的结构。我建议为您的每个 WCF 服务编写一个“服务”类，并将每个服务注册到您的容器中，这样您就可以在需要任何特定服务的视图模型上使用 ImportingConstructor。您将在引导加载程序中初始化和注册这些类。此时您可能会问自己是否真的需要 6 个，也许应该考虑合并到 1 个 WCF 服务中。
d) 我不同意塞巴斯蒂安的观点。如果您的服务很简单，那么 WCF 配置就很简单。您需要的越复杂，配置就越复杂。默认情况下，您只需要很少的配置，我会查看 Visual Studio 附带的 WCF 服务配置编辑器工具来修改您的 app.config 和 web.config，但不要混淆您正在处理哪个！配置客户端的最简单方法是使用“添加 Web 引用”并指向服务器计算机上的 URL。请记住，WCF 允许您为同一服务配置多个端点（端点是带有端口和服务名称的 URL），并且每个端点可以具有许多不同的协议之一（我使用 basicHttpBinding、wsHttpBinding 或 netTcpBinding，具体取决于根据我的需要）。我建议从 wsHttpBinding 开始，这是最容易调试的一种。手动修改 app.config 或 web.config 会给你带来麻烦，因为一个错误的输入，你就会调试好几个小时。坚持使用编辑器。
e) 您将找不到关于 Prism 和 WCF 的良好参考，因为其中一个不会影响另一个的实现。通过将您的 WCF 服务代码封装在由容器在 Prism 中提供的服务类中，您可以消除 Prism 本身与服务之间的任何依赖关系，并且以后不会因为无意中将它们耦合在一起而让自己头疼。稍后，您可以使用 Moq 服务类注入视图模型，该服务类不会出于测试目的调用实际服务。 Prism 有一个非常好的 CHM 文件，其中包含您需要了解的有关 Prism 的所有信息，WCF 在 Microsoft 的网站上有很好的文档（不需要书，除非您想花哨，比如使用那个 Windows 服务）。
随时跟进。
跟进#1：
由于我使用 IIS 来托管我的服务，因此我没有经验指导您为多个服务实施 ServiceHost。但是，IIS 允许将多个服务放入同一个应用程序池（这基本上是在您的机器上运行的 W3WP.exe 的单个实例），所以我很确定它可以做到。
编辑：阅读您提供的 WCF 指南后，我可以看到您在 EXE 中为要托管的 每个 服务创建了一个 ServiceHost 实例。所以你需要 6 个 ServiceHost 实例，并在 EXE 代码中分别管理它们。
考虑您的服务是一个设计问题。您选择为每个域类提供一项服务。如果我在我的应用程序中这样做，将会有超过 100 项服务。相反，我选择了一个命令模式来实现一个命令模式，它允许我对我想要的对象发出请求，无论类型如何，它都会在一个干净的界面中将它们返回给我。
我相信您不会在任何书籍中找到有关在 Prism 和 WCF 之间完成设计的指导。您可能会在博客中找到一些内容，但是，我建议您这样做：
将您的 WCF 服务创建和操作封装在一个类（例如 DataAccessService）中，该类可以通过依赖注入注入到您的视图模型中（请参阅 ImportingConstructor 属性）。如果发生错误（或其他可通知事件），请使用 eventtaggregator 服务从 DataAccessService 发布事件，并在视图模型中处理它们。不要通过直接调用它们来在视图模型或视图与 WCF 服务之间创建内聚，因为这将违反 SRP 并阻止在不接触 Web 服务（外部依赖项）的情况下测试视图模型的能力。