简单描述：
accountServie,adminService....很多小的service接口，再建立一个facadeService，把这些小的service包含进来，这样facadeService就可以看做整个项目的一个方法库，项目中所有的方法都在这里存在。
每次调用其中的一个方法，facadeService会不会被创建一次，还是系统启动后，只创建一次facadeService，每次用时，直接取，就像factory一样 ??
facade设计模式在哪些情况适合用呢，庞大的项目（500个方法以上），还是小的项目（不足200个方法）？
项目大了以后，难免会有重名（参数也一样）的方法存在（但返回结果不同），由于只是存在于不同的包体下面，他们是没有冲突的，但如果对被引到facadeService里面后，会不会有冲动呢？
坚决不能这么做。
这会导致facadService很大，下面问题：
1. facadService接口意图不明显，facadService凭什么而存在呢？facadService因为太大太笼统就失去存在意义。
2.扩展差，新增service都会导致facadService修改，破坏封装性，带来潜在BUG。
3.容易导致过程性编程，过程编程和OO一个最大区别就是，过程编程喜欢将所有东东放在一个篮子里，导致你我不清。
所以，facade模式慎用，不是什么特别好的模式。
我认为facad要封装一个子系统，这个系统从全局来看是个独立性强的模块。
没状态的当然可以就创建一个，有状态就不行了，特别有两个或以上状态，而且这俩状态还服务于不同的更小的子service，这时候这样做就浪费掉对其中一个状态的维护了，因为同时只应用了一个状态，但却不得不管理另一个。
我觉得facade可以用来封装一下业务逻辑，当我们的领域模型实现了业务逻辑以后，我们可以采用ejb facade或者pojo facade来封装，这样facade实现事务边界的划分，不然的话也可以采用暴漏领域模型的模式。不过我个人还是喜欢用facade来封装一下业务逻辑。
当子系统关系复杂，为了减轻客户端调用，facade还是需要的。banq不能一块砖给拍死。banq中可以设置事务边界。领域层不需要设置事务边界。有利于保证领域层的纯洁性。ejb facade,或者pojo facade都可以。
用factory来get这些service不比facade更好么？？
很久以前一篇文章供参考:J2EE中几种业务代理模式的实现和比较，文中比较了factory command 和IOC/AOP的几个特点：
感谢banq及各位热心的朋友。
项目中应用的facade模式就如我题目所说，它最后就相当于一个方法库，不管是谁，要调用什么方法，直接来取方法传参数就行了,最后facadeServiceImpl体积庞大.
还不如不用，直接调用几个实体相应的service就可以了，反而觉得facade有些没必要存在。