我的Spring 全家桶架构的设计之理想和现实。

前言

模块化组合成新产品一直是我所想象的事情，每一个新开发的模块都可以被很好的保存下来，并且可以一直升级并使用。

理想

• 使用 user模块+good模块+order模块+payment模块+shop模块 = 购物系统
• 使用 user模块+good模块+order模块+payment模块+ kickback模块 +shop模块 = 提成购物系统
• 使用 user模块+site模块+order模块+payment模块 = 通用官网系统
• 使用 user模块+site模块 = 独立官网系统
• ...... 想象如此美好。

现实

为这个理想我已经进行4个产品的应用，发现模块化越是极度的产品维护起来越是困了，我开始思考我这个理想存在的问题。

• 引用上面理想A : 使用 user模块+good模块+order模块+payment模块+shop模块 = 购物系统
• 引用上面理想B : 使用 user模块+good模块+order模块+payment模块+ kickback模块 +shop模块 = 提成购物系统
• 现实: goods 、 order 模块都需要集成4～5个其他业务相关的模块，导致业务代码难以理解和维护。

平衡

经过3年多的实战，每个品模块及带又强关联关系的模块必须重新开发，例如现实中的 两个购物系统 goods 模块+上了kickback模块，就需要设计成. business_good 重新定义good 不要使用组合。这个例子比较简单，实际应用可能要包含这样的模块 4～5个， 查询及实现业务，带来的前所未有的挑战。

总结

需要很有经验的区分出可组合和不能组合模块，如果经验比较少的同学，直接按照业务必须重写原则即可。希望给有和我一样想法的人一些参考。