I'm having troubles applying my domain model design choices into Spring architecture, and I'm hoping one might give me enlightening ideas
In almost every Spring sample application I've seen, I usually see one or several Services (call this Facades or BO), each one of them using injected DAOs to perform the real business job. This is fair, and working fine, however I would like my application to have some kind of "super service", acting as a delegator to several other classic services, each one of these classic services then being injected with DAOs. On top of that, I also need my DAOs to be able to lookup each other's methods.
A straightforward example would be :
I have a fooService using aDao and bDao, and in my bDao implementation, I need to lookup aDao methods, because the bDao business process is being altered based on data being accessible through the aDao. Then I need a superFooService, being able to control this fooService, but also barService, xxxService, and so on.
Is this a Bad (tm) architectural practice, and if not can I still wire Services together via Spring ? I smell that in order to make DAOs talk to each other, I may need to use their parent service as a communication bridge between them, but this sounds like the DAOs would need to lookup their parent to see the "outside world", and I can't figure out if this is regarded, too, as a bad practice.
Is the "one service to bind them all" practice recommended, and if it is, how am I supposed to have the underlying DAOs know about each other ?
Thanks for any input