Good OO practice indicates that one applies "separation of concerns" to put like subject matter within a unit of code and minimize the interface between that unit and all other units. I say "unit" because domain, layer, subsystem, and package all have different meanings to different people (including, "I don't like using that word") and I don't want to get forked into discussing what is meant by each right now. Often, one provides the "unit" with a Façade object which presents a simple interface to the outside world and which manages the interaction of objects within the "unit" to fulfil requests.
If one is thinking in these terms, then it also seems like these "units" should be managed by some kind of "session manager" not merely started up as needed by some other unit that needs the service. Perhaps I won't get universal agreement on this, but it seems to me that having unit A start unit B tends to imply that B is somehow subordinant, which is not. Moreover, if C also needs B, one doesn't really want C to start another instance. One can avoid that with statics, but then one has no way to clean up when something is no longer used.
So, if anyone is still with me, I am wondering what patterns people are using for this management. Are you using a session manager to start each unit? If not, why not? If so, what does it look like? And how do you manage the communication?
Let me supplement this by saying that some also consider it good OO practice for such communications between "units" to be merely data messages, not actions. Thus, A should say to B, "X has happened" and leave it up to B to decide what to do with it, rather than saying "do Y with X for me." Obviously, A may have "expectations", e.g., if it notifies B of an interest in customer 1, it rather expects B to hand back the info on customer 1. The distinction is that the data message is very loose coupling and assumes nothing about how B will implement the request, whereas calling a direct GetCustomerInfo method tends to provide very direct coupling.
I am thinking that the session manger really only needs to keep track of the Façades and leave it to each Façade to keep track of its contents.
I am thinking that possibly all messages could flow though the session manager to limit the amount of coupling between each "unit". In particular, this would allow the use of class events for a Façade to subscribe to messages from the manager, thus providing a kind of event driven sequence of actions. This would mean that the session manager "knew" about each Façade and could thus push messages to it, but each Façade needed to "know" only about the session manager, so it could push messages to it. Messages in the opposite direction could be via class events.
This is hardly the first version I have come up with, so I am sure there are others and I am curious what other people are doing for this aspect of their architecture ... or whether they are working from entirely different assumptions about how things should interact.
What about using a Registry? I'm not suggesting a full-blown LDAP or anything like that. A registry object in an application could allow each layer or subsystem to register itself. Then, any subsystem that needs the services of another can get a reference to the service interface from the registry.
I'm personally not a big fan of centralizing the delivery of messages, unless your architecture requires something like publish/subscribe or broadcast.
What I am doing at this point is providing a registry and an incident queue. Each domain has a facade object which is the only object outside the domain that anyone talks to and the facade registers itself when created. Messages are sent to the facade which forwards them to the incident queue, If an incident is a message, it is forwarded to the facade of the appropriate domain which knows what internal object to direct it to. If the incident is an event, then it is routed to the object which is the focus of that event. This keeps good isolation between domains.