JefZ

果然对于旁人的痛苦是缺乏想象力的，
写代码的人才会真正在乎改动带来的困难，后期开发的复杂度，心智负担重，debug 变得更难，性能不好了。

感谢大家提供参考

@shunia @tianzi123 @yimov2 @shadowyue @laommmm @shunia ↓

> 增加后期心智负担

这是最恐怖的。我们现在的模式挺好的，新的框架基于 Next ，相当于提供了初始化项目的范式，正正常常，没有垂涎的优势，复杂度守恒，除了可以统一框架，不一定能带来什么优化，边际成本变多。


@beq ↓

> 于是根据功能将其划分多个子系统，

哥你这个拆的太彻底了，这变成了彻底的前端微服务，每个子系统独立的很，我们应该没法和你们一样拆的这么彻底。

@rockey1997 @zy0829 @lee88688 @mygao666 ↓

> monorepo

好主意。深化一下我们现在的项目结构。

* 统一技术栈，项目按照 DDD 的思想，每个有边界的业务有自己的 domain ，几个 domian 结合起来就是 monorepo 中的一个 package 。现在我们不同的 domain 之间就互相干扰，每个团队这里引用一下那里导出一下，拆分成 package 也应该不会好转
* 独立，独立构建，独立配置，因为原来就是统一的栈，所以独立后，无非是复制一份基础的配置和构建过程。
* 项目的公共依赖，几乎每个 domain 都使用到了，没有一个 domain 有的依赖别的 domain 没有的场景。所以不存在依赖管理的问题。
* CICD 么，bundles 包都被上传到了 CDN ，要服务器没有用。只有主应用因为要 SEO 和服务器端逻辑才需要服务器。大部分 domain 就安静的待着，没有服务端逻辑，静态文件服务都不需要。

这种情况下，monorepo 的优势在哪里呢？因为没有做过，所以无法理解真实的项目问题和好处。

@jones2000 ↓

> 聚合网关

我们有 BFF 。BFF 也要迁移。这就是另外的问题了。涉及到 BFF 和后端的访问延迟，访问权限。

----

补充背景：
这个主题主要是关注技术，但是我想增加一些额外的东西来说明我们除了技术上的选择，还有非技术的压力。
新的公司架构有一套自己的，封装了 Next 的框架，围绕着这个框架有很多额外的依赖（比如翻译，配置）。高层决策希望统一技术栈。我们自己也挺想用新的体系，问题在于不想为了统一而统一，因为我们属于成熟项目，大家不都说理想的技术决策是基于理性表达代码嘛。