微服务组件的前端代码分布在每个微服务中，用一个前端项目做聚合的思路好吗？

Question

首先请您理解一下业务：我们一直按业务做模块化，一个微服务模块包括后端代码和界面。
传统的java开发的微服务，mvc模式（后端渲染）下，界面（jsp或freemarker)代码也放在同一个java工程里，这个微服务的开发者通常是前后台一起开发。我们会把一个微服务打包成组件jar包。有很多应用或站点会使用这些微服务组件。
而在前后端分离前端工程化模式下，每个应用或站点会使用一个单独的前端工程，但每个应用或站点会使用不同的微服务，比如一共有100个微服务模块，作为一个SaaS服务的基础，每个租户应用会用到不同的5-20个微服务模块。
那么问题就来了，传统上，后台服务和界面按业务封装在一起，访问时后端渲染没有问题，但前端工程化后，每个应用有一个前端项目，需要有这个应用用到的5-20个微服务模块的前端页面。通常的方式，前端团队会调用后端5-20个微服务的api，自己开发构建前端代码，但这样就无法完整地封装业务了，我们希望能复用业务模块。
我想这样做，在java微服务工程中，加一个目录放前端的vue组件（开发测试完成后放进去），打成jar包发布。其中有个接口可以向指定的前端工程目录复制这些vue文件，前端打包时调用这个接口聚合所需的5-20个微服务的vue文件后再进行npm run build打包。每个多租户应用打一个自己的前端项目包。
也就是说，一个团队负责一个业务模块的前后端代码，前后端可以用不同的IDE来写，写好测试后都放到java项目中，实现完整的业务组件。真正使用时创建租户应用时，再把各java项目中的前端代码聚合打包，我感觉这样做似乎背离了前后端分离的初衷--让专业团队做前端的事，有点牵强，似乎为了用vue而用vue,但现在如果还坚持用jquery,总感觉跟不上时代。但是按常规的前后端分离模式，每个租户应用再由前端团队单独处理也不合适，而且分为前后端团队后，成本加大很多，两边都要精通业务。请大家不吝指教！