The goal of my project is to create a centralized source of business/domain logic to support several of our business applications that currently duplicate process, rules, etc. And while not every benefit of modularity will be achieved, I'd like to seize the opportunity to establish a framework that will leverage those parts we can take advantage of.

First question is where do I define this interface? If the goal of modularity is the ability to swap implementations, then wouldn't I want the interface in a common location? On the other hand, maybe it's preferred to have each module self-contained in that it has the interface and the implementation. I'm leaning towards a shared MyApp.Contracts assembly that defines all of the contracts used by the service API. The modules can reference this assembly and provide implementations and the IoC configuration is used to tell the app which to use at runtime.

Another option, since I'm a big fan of keeping the service layer thin (facade pattern), I could have a MyApp.Services "module" that contains the implementation of the service contracts which simply delegate to another class which contains the domain logic for the operation. For example, the FinanceService WCF class delegates to another interface which is implemented in the Finance module to carry out the operation. This would allow me to maintain a thin service facade and 'plug-in' the implementation to the service implementation and eliminate the need for the modules to worry about WCF, for instance.

Next up, sharing information between modules. Take, for instance, a Receiving operation. At first blush it makes sense that this goes into the Inventory module as receiving goods is an inventory function. However, there is also a financial aspect in that we need to generate a Receipt and authorize payment.

On the one hand, I would expect to use some type of domain events / messaging to communicate the operation. So, the Inventory module raises the GoodsReceivedEvent which is handled by the Financial module to generate the Receipt and initiate the payment process. However, this means that the Financial module needs to know about the inventory items that were received. I can simply refer to them by ID but what if I need additional information for the Receipt, such as the name and/or description, unit cost, etc.? Does it make sense for each module to have their own version of an inventory item that is designed to suit the needs of that module? In that case, the Financial module would have to perform its own lookup of the inventory items when handling the GoodsReceivedEvent. Where do I draw the line between modularity and the need to share information?

Background

The goal of my project is to create a centralized source of business/domain logic to support several of our business applications that currently duplicate process, rules, etc. And while not every benefit of modularity will be achieved, I'd like to seize the opportunity to establish a framework that will leverage those parts we can take advantage of.

1. Should the service layer implement the API and delegate to the modules or should the modules be self-contained (in that they contain everything related to that module, including the service implementation)?

One way of approaching the problem is to have a MyApp.Services "module" which contains the implementation of the service contracts. Each service class simply delegate to another class int eh appropriate module which contains the domain logic for the operation. For example, the FinanceService WCF class in MyApp.Services delegates to another interface which is implemented in the Finance module to carry out the operation. This would allow me to maintain a thin service facade and 'plug-in' the implementation to the service implementation and eliminate the need for the modules to worry about WCF, for instance.

On the other hand, maybe it's preferred to have each module self-contained in that it has the interface and the implementation. The service host refers to the service contract interface found in the module and the IoC is configured to use the appropriate implementation from the module as well. This means that adding a new module can be done with no changes to the service layer other than adding a new .svc file and IoC configuration information.

2. What is the best way to handle sharing resources between modules and/or dependencies between modules?

Take, for instance, a Receiving operation. At first blush it makes sense that this goes into the Inventory module as receiving goods is an inventory function. However, there is also a financial aspect in that we need to generate a Receipt and authorize payment.

On the one hand, I would expect to use some type of domain events / messaging to communicate the operation. The Inventory module raises a GoodsReceivedEvent which is handled by the Financial module to generate the Receipt and initiate the payment process. However, this means that the Financial module needs to know about the inventory items that were received. I can simply refer to them by ID but what if I need additional information for the Receipt, such as the name and/or description, unit cost, etc.? Does it make sense for each module to have their own version of an inventory item that is designed to suit the needs of that module? In that case, the Financial module would have to perform its own lookup of the inventory items when handling the GoodsReceivedEvent. Or do I now have to put my domain objects into a shared location (at which point I lose some cohesion)?

...

Any help getting my head wrapped around this are greatly appreciated.

Any help getting my head wrapped around this is greatly appreciated.