您当前的位置: 要做一个相对功能比较多的系统，是否应该把有的功能拆为一个个单独的Project，这些Projec都相当于一个组件。但是这些Project之间怎么能很好的整合呢？它们之间用什么样的通讯机制比较好呢？希望有经验的朋友不吝赐教，没经验的朋友积极讨论，不胜感激！！！
------解决思路----------------------
以下是我的一些经验总结，希望对你有点帮助：
http://blog.csdn.net/kmtong/article/details/39052199
------解决思路----------------------
功能多的需要 拆分为多个子项目也是对的， 大家公用的组件是一个项目，其他项目各自业务上独立，如果彼此间有通讯，则考虑接口实现的方式： 比如：直接数据库通讯 还是 通过hessian 这种第三方框架来实现基于服务层的接口.
------解决思路----------------------
没听企业设计模式中说么 能不用分布式就尽量不用阿,组件化是否真的有必要啊?如果确实要拆分,是根据什么拆分要能清楚,是按照业务还是什么你根据自己的情况,我习惯从底层向上拆分,即把数据库作拆分建模;拆分后没问题就可以 封装不同的model层了,公共的业务抽象出来并作为公共模块,调用方式 尽量选择轻量级的框架,java rmi hessisn等;前台其实可以用portal方式整合,把所有菜单和工程建立对应关系,这种方式注意单点的实现,我们公司用的是cas来实现单点.这些是我工作中遇到的 希望可以给你点帮助,也希望有人提出更好的方案改进
------解决思路----------------------
还没有做这么大的项目，期待中。。。
------解决思路----------------------
用sso集成，通讯用ws，还有DB
------解决思路----------------------
各组件系统间可以通过RPC交互，推荐用netty作为通讯框架，用protobuf作为通讯对象载体，经我们实践，这个体系性能、可维护性上都很优秀。
------解决思路----------------------
按照你的说法，简单点的就用WEBSERVICE，如一个大的功能，涉及到与其他系统交互的，或者采用多线程的技术。这多少能解决点问题，再复杂的，恕我能力有限，其他的只限于知道，但是没有实现过。
------解决思路----------------------
楼主的项目要是非要这么做的话，现在已经有相当成熟的osgi技术了，很多大型企业的web项目都是这么搞的，不过一般都是基于osgi的比较成熟的框架，你要是想重新搞的话路还很长。
具体来说osgi就是实现了模块化，不同功能不同的project，可以吧所有jar包都放在一个project里，然后每个大模块一个project，相互之间通过暴露和引用关联，要这么做需要找一个熟悉业务和框架的架构师来好好设计下，不然以后可能会出现project重复 依赖等等架构层面的问题。
所以不建议任何少于50人团队、而且没有自己成熟osgi框架的项目来做这个工作，得不偿失，完全没必要。
------解决思路----------------------
项目和服务的拆分，导致交叉依赖问题，建议业务越高的项目只能向下依赖，通知服务间的调用可以使用zookeeper管理
------解决思路----------------------
我们公司就是用的这种模式的。分多个模块，各个模块之间依赖关联，
像这样子。刚进公司的时候搭个工程都搭得要死。不过比较方便。本机部署启动的时候。如果只要测试某个模块中的东西。只需要加载某个模块就行。
------解决思路----------------------
这种依赖性太强，很容易让人晕掉的...如果在前期严格按照功能来划分模块还好，一旦划分不是很明确，后期维护挺麻烦的
------解决思路----------------------
拆分之后，可能立刻就会增加10甚至200毫秒的性能延迟。所以拆分一般来说应该在两个方面考虑：
1. 异步业务逻辑看上去更优美更清晰。当前的业务并不急着要结果，因此完全可以异步执行。
2. 或者不是异步逻辑，但是系统的CPU实在是支持不了了。
否则，不要拆分。