Mvc – Modular enterprise architecture using MVC and Orchard CMS

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?

You will always have to accept trade-offs. That's all there's to say to your questions really. It has been a good practice to keep the entities in a separate assembly, so many applications keep them in a shared library. But that means that there're no (physical) business-logical boundries. Performing your own lookups means a lot of redundant code which I'd only implement if you have special requirements in both the modules. Of course, looking at it from an architectural point of view, your Financial Module and your Inventory Module have to share a dependency anyway. The Financial Module is most likely dependent on the Inventory Module. If requirements permit you to let one module depend on another module, then I'd say it's ok to encapsulate the entities within the modules they belong to the most. You'll need to find a good balance between physical distinction (shared dependencies) and maintenance. Too many shared dependencies could cause a maintenance nightmare of versions. Also, with an ORM there'll be troubles if you want to map new relations to existing entities or extend them from modules which depend on the module containing the entity.

If you don't use ORM then keep in mind all your modules probably share the same database anyway, as that's often the case. You could use that as a common ground.

You could also keep the data plain (in terms of CSV/resultsets e.g.) and use a central messaging service to notify modules that registered to it about new data with along with some meta information. That means no real dependencies, but sacrifices type safty and contracts and there can be troubles with malformed data. I guess that's how many big ERP systems do it.

So in short, you'll have to decide which kind of interface you want. More modularity leads to less contracts and vice versa.

Id'probably use a shared library for my data objects and a central messaging service with a publish subscibe pattern, that seems the best solution to me.

The purpose of modules and frameworks is not so much to achieve independence of functions as it is to achieve reusability and flexibility. In most other occupations, this kind of reuse of function and flexibility is central to achieving success.

Think about how difficult it would be to work on your car if you had to buy a whole new tool set for each car, because the tools were not interchangeable. Or worse, you hae to build the tools from scratch, because there wasn't a factory to create them. Both of these concepts (universal pluggability and object factories) are present in well-written modules and frameworks.

...but each project is different and usually involves building many layers of abstractions to add new features - or editing the files directly to customize them. I can't re-use the same module on multiple projects.

You are describing tight coupling, an undesirable trait of software that's intended to be reused. Properly written libraries, frameworks and modules achieve loose coupling through software patterns such as Inversion of Control, message passing, and universally-understood communication methods such as REST and XML. These are not the only methods by which loose coupling can be achieved.

Obviously, it is impossible to write a completely decoupled system; one part of the system has to know something about the other part of the system, or nothing gets accomplished. But a high degree of decoupling can be achieved nevertheless.

Writing modular software takes more work and forethought than writing tightly-coupled systems, but the effort can be worth it, especially when writing a framework or library that will be used by many people.