By having a Facade you can get away with calling multiple CxBusiness
objects and integrating their operations into a meaningful result. That is the purpose of a Facade, to simplify the interaction with the Business layer by hiding away interactions of 5 different components behind a concise and clear operation: methodOne
.
For the individual CxBusiness
however, you want to avoid cross-calling among each other; otherwise, you will end up with a complex dependency structure that could potentially run into circular references. Keep each CxBusiness
as the sole wrapper for each Cx
model and you will reduce the number of unwanted side-effects when interacting with them. Any interactions among these will take place in the facade.
Furthermore, enforce this pattern by having the facade depend upon interfaces rather than concrete classes: ICABusiness
, ICCBusiness
, etc. Then, the only way to access any model should be through these interfaces, and obviously, you should not have a concrete CxBusiness
with a ICxBusiness
member (no cross-dependencies). Once you put these restrictions in place, the implementation itself will flow towards a more modular and less coupled design.