项目开始大概是18年初自己便于学习立项的，原为了便于学习而做的技术分享，这里只是阐述自己团队整合过程的总结参考。

概述

经过这几年的实践和项目迭代，经验总结，还有过程中的各种坑点总结，包括企业走向，团队整合等，发现基线存在大量的设计问题（这里指的问题并不是技术，而是设计）。

后期团队的不断丰富完善，形成了一大型项目仓库，整个仓库已经变得非常的庞大，同时子目录下面集成多个工程和组件，近乎上百个maven工程，如图：

关闭原因

容易让企业和团队走极端路线，而产生大量的内耗，而产生这一过程的问题，要回头，少则2年，多则需要3-5年的时间。

当然，另一种办法是过程中架构师的不断重构，这是可行的，但是针对于中小团队来说，重构和架构师的成本，还有周期成本都非常大，特别是切换架构师或者核心人员的情况，除非能完全掌握整个设计思想。

但即使是这样，新旧项目的迭代，还有维护，也会消耗至少超过半年以上的内部资源，新旧项目迁移，特别是上生产的项目。

针对于企业和团队来说，1-3年是发展的周期，产生的内耗，这里的内耗不仅仅是项目的内耗，还有团队，方向，公司，战略等，后期进一步发展容易掉队，特别是在当前数字化快速的情况下。

保留原因

为了更方向的学习和参考，因为原设计文档还存在，相对于文档和代码的对照来说，可以进一步的学习，对新人是有一定的帮助，但是切入实际的项目并不太建议。

同时也考虑通过设计文档和相关的资料，可以在后期自己方便的时候，直接搜索获取，同时在过程中有一个历史记录的意义存在。同时是gitee的GVP项目，原来并不了解开源项目的运营规则，关闭过一段时间，对相关关注的用户和学习中的用户，还有gitee平台的影响未深入考虑。

其它

针对于中台库的不断变大，同时也体现出中台库的历史包袱也变得沉重，于21年的时候，为了更好的切入数字化建设和跟进行业的发展，进行的中台拆分，由原来的大中台，小前台，变成了轻中台，小前台，大平台的架构思想调整。

待梳理文档：我把整个研发中台拆分过程的一些心得总结

原项目地址（建议学习使用) ：https://gitee.com/landonniao/linesno-cloud-service