What about the module?
We rightfully create objects that are loosley coupled and cohesive - you bet. But, we fail to look beyond the object level to that of the module. All things being good, these modules should exhibit the same traits - being highly cohesive and loosley coupled. So what are we really saying here? Well, we’re looking for controlled ways for modules to communicate with one another while limiting dependencies on one another. We’re looking to provide a single interface, representative of the module concept; To facade multiple sub-module interfaces which cohesively describe how the module performs its function.
Further, we’re looking to extract entities that have identity across all modules. These we abstract to a meta layer (call it what you will) and provide to modules via injection. Thus reducing module dependency on one another.
A poor example: A system that stores information about members, their subscriptions and the events they wish to attend. Modules might be:
- Membership - capture, modify and return membership details
- Subscriptions - Fees and subscriptions associated to members
- Events - Organising and booking of industry events, members my wish to attend.
Module interfaces should reflect corse grained functionality - “what to do” rather than ”how to do it”. Our meta layer would definitely have a Member entity since its common to all modules - holding identity across the entire system.
I could go on but I’m hoping this is enough to get the coggs whirring in there. Its really no different to the decisions we make at the object level. However, it does change the forces acting on design decisions at the object level … thoughts?
