项目模块划分合理性的问题
一套可以接很多第三方的管理系统，原来是想做成接一个第三方就建一个子工程，这些子工程引用公共代码工程，但是发现有的公共管理页面的操作需要用到各个第三方子工程的业务，但是公共工程没法引用这些子工程。现在有两种考虑，一个是再建一个公共管理的工程，把各个第三方子工程都引用进来，另外一种方式就是把这些子工程都合并到一个业务工程里，用各个子模块的形式划分，然后在这个业务工程里建个公共管理的模块，这样就能直接调用所有子模块的代码了。
不知道这两种方式哪种更好？主要是想知道在一个工程下划分出不同的模块和独立建一个子工程这两种方式的利弊。要考虑的维护和开发的方便程度，因为每接一个第三方就会独立开出一个分支进行开发，同时开发完成后就会变成稳定版本，生产版本的维护在稳定版本上。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
soa架构啊，每个第三方调用服务建一个工程 ，向外提供http接口，对内调用第三方的服务；总线制定接口，调用各模块
对于管理系统的需求，建议进行系统分离，管理系统与业务系统隔离，以管理系统为需求出发，制定接口标准，业务系统按接口开发，并在管理系统进行注册
关于一个工程下划分出不同的模块和独立建一个子工程这两种方式的利弊
模块还是子工程的选择主要看你的业务场景，负载数据量情况，在访问量小数据量小的时候，模块开发肯定是利于团队开发的，模块的话架构设计服务器部署复杂度都低的很
但是你的子工程的业务重合度到底有多高，重合度高的话建议用saas模式，做成一套系统，如果不考虑这个，重合度高的业务功能升级迭代对于你很多子工程的时候，将会很痛苦，所以重合度越高越建议走saas模式