我正在考虑设计一种本质上是模块化的新解决方案，并希望创建一个支持该设计的结构，以便将来轻松进行扩展，明确分离关注点，按模块进行许可等。在网络上发现的关于模块化或组合应用程序的是以UI为中心的，专注于Silverlight，WPF等。就我而言，我正在开发WCF服务应用程序，该程序将由从事各种UI项目的其他开发人员使用。
背景
我的项目的目标是创建一个集中的业务/域逻辑源，以支持我们的多个当前重复流程，规则等的业务应用程序。虽然并非可以实现模块化的所有好处，但我想抓住建立一个可以利用我们可以利用的那些部分的框架的机会。
我通过查看服务应用程序公开的API来开始设计。显然，可以按照我所考虑的模块化路线来隔离服务。例如，我将拥有FinanceService，InventoryService，PersonnelService等服务，这些服务将我的服务操作分组以在API中提供高内聚性，同时保持较低的耦合度，因此客户端仅需使用与他们的应用程序相关的服务。
对于我来说，我可以为每个服务分别拥有单独的模块，例如MyApp.Finance，MyApp.Inventory，My.Personnel等。跨领域关注点和共享类型将在MyApp共享程序集中。从这里我有点束缚。
（哦，我应该提一下，我将使用IoC容器进行依赖注入来保持应用程序的松散耦合。我不会提及哪个容器，因为我不想打开Pandora的盒子！）
在MyApp.ServiceHost中，我将创建一个与每个模块相对应的服务宿主文件（.svc），例如FinanceService.svc。服务主机需要服务的名称，该名称与配置文件中的信息相对应，该配置文件包含定义服务合同的接口。然后，将IoC配置用于映射要使用的接口的具体实现。
1.服务层应该实现API并委托给模块，还是应该使模块自包含（因为它们包含与该模块相关的所有内容，包括服务实现）？
解决该问题的一种方法是拥有一个MyApp.Services“模块”，其中包含服务合同的实现。每个服务类都简单地委派给包含该操作的域逻辑的相应模块中的另一个类。例如，MyApp.Services中的FinanceService WCF类委托给另一个接口，该接口在Finance模块中实现以执行操作。例如，这将使我能够维护精简的服务外观并将实现“插入”到服务实现中，并且无需使模块担心WCF。
另一方面，也许每个模块都是独立的，因为它具有接口和实现。服务主机引用模块中的服务合同接口，并且IoC也配置为使用模块中的适当实现。这意味着除了添加新的.svc文件和IoC配置信息外，无需更改服务层即可添加新模块。
我正在考虑如果从标准WCF切换到RESTful服务接口，或者转而使用RIA服务之类的影响。如果每个模块都包含服务合同的实现，那么如果我更改服务技术或方法，则必须在每个模块中进行更改。但是，如果外观是其自己的模块，那么我只需要换出该部分即可进行更改。然后，这些模块将必须实现一组可能在共享程序集中定义的合同（接口）的不同集合？？？
2.处理模块之间的资源共享和/或模块之间的依赖关系的最佳方法是什么？
以接收操作为例。乍一看，这很有意义，因为进货是库存功能，因此进入库存模块。但是，在财务方面，我们还需要生成收据并授权付款。
一方面，我希望使用某种类型的域事件/消息传递来传达操作。库存模块引发一个GoodsReceivedEvent，该事件由Financial模块处理以生成收据并启动付款过程。但是，这意味着财务模块需要了解已收到的库存项目。我可以简单地通过ID来引用它们，但是如果我需要收据的其他信息，例如名称和/或描述，单位成本等，该怎么办？每个模块都拥有自己的版本的清单项目以适应该模块的需求是否有意义？在这种情况下，财务模块在处理GoodsReceivedEvent时将必须执行自己的库存项目查找。
...
我之所以使用此示例，是因为我已经与各种ERP系统进行了大量合作，并且知道它们是采用这种类型的模块化设计的-我只是不知道如何操作。我上面也没有明确提及，但是我更喜欢遵循域驱动设计原则来设计解决方案，并相信这种类型的模块化恰好适合该领域。
非常感谢我对此有所帮助。