There is a quite general interface model that is commonly used for subsystems. This model addresses a common problem found in large scale reuse. Because there can be multiple syntaxes for accessing any complex semantics, it is always possible that a new client in a reuse situation will want to access the semantics using a different syntax than the service actually provides. In that case context-specific "glue" code is needed to resolve the syntactic mismatches. (In the context of application partitioning, access syntax is defined as the interface.)
The basic model is:
+-------------------+ +-------------------+ | Subsystem A | | Subsystem B | | +------+ +------+ | | | Ain |<-----------------| Bout | | | +------+ +------+ | | | | | | +------+ +------+ | | | Aout |----------------->| Bin | | | +------+ +------+ | | | | | +-------------------+ +-------------------+
The basic idea here if that subsystem interfaces are actually two-way and they provide both an input interface and an output interface. The input interface, Xin, is a traditional interface that accepts messages and dispatches them to the appropriate objects within the subsystem. The output interface, Xout, does the same thing in reverse; objects within the subsystem that wish to send messages to the outside world address them to the Xout interface. Both Xin and Xout are typically implemented as Facade design patterns. That is, the interface is a class with its own implementation that provides dispatching services to other classes.
The Xout interface dispatches to the other subsystems Xin interface. If any "glue" code is required to resolve syntactic mismatches, it is provided in the Xout implementation. This isolates the "glue" code to the implementation of the Xout Facade class. This is important because the objects that implement the subsystem "see" only the Xout interface, which is always the same, regardless of reuse context.
The isolation of the "glue" code completely decouples the subsystem implementation from the outside context. This is also very practical because it is consistent with modern development environments. For example, the Xout interface class can be implemented separately, provided in DLL form, and simply linked into the application. It also allows things like networking protocols to be isolated when a subsystem is deployed in a distributed environment.
However, the main benefit lies in the decoupling of the subsystem implementations. The only part of the subsystem with any knowledge that the other subsystem even exists is the implementation of the Xout Facade. This essentially provides "firewall" interfaces within the application that modularize and isolate the application's partitions. Of course that only works well if the interfaces themselves are highly disciplined (e.g., event-based). But if the partitions and interfaces are defined according to the ideas expressed in the other posts in this category, then one has an excellent architectural framework that will be stable over time.