Software Architecture – How to Think When Grouping Functionality into Modules

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.

Except for the tiny comment at the end (second, supervising CPU) you could be describing my company. Yup, we need Easter too.

Well, we're a bit further along. We did split the big executable and tried to use standard components for standard bits. Not exactly the big improvement you'd hope for. In fact, performance is becoming a major pain even on beefier hardware. And maintenance costs haven't really gone down now that there's tons of code to serialize and synchronize data over narrow interfaces.

The lesson I've learned? Having a single executable is a well-proven solution for small systems, and we have decades of experience in managing it. All our tools support that natively. Modularity can be done within a single executable, too, and when you need to compromise on modularity for other reasons the hack remains small.