docs: add monorepo

docs/monorepo/introduce.md

@@ -0,0 +1,29 @@
+## 从MultiRepo 到MonoRepo
+MonoRepo 其实不是一个新的概念，在软件工程领域，它已经有着十多年的历史了。
+
+概念上很好理解，就是把多个项目放在一个仓库里面，相对立的是传统的 MultiRepo 模式，即每个项目对应一个单独的仓库来分散管理。
+
+![repo.png](repo.png)
+
+通过上图的对比可以看出MonoRepo模式更适合当前及后续的的项目组织管理，也使得代码复用、以及统一的工具库、组件库等项目基础建设更为容易，当然也对开发人员的代码质量要求、代码审查更为严格，这也反过来促进了前端研发人员的技术自我提升。
+
+## 巨石应用
+
+随着项目增多，产品权益的边界模糊，复用某业务的复杂度也逐步上升，已经无法按照旧的产品分层来规划项目，对需求也很难快速调整和支持。
+
+思考把现有项目聚合，转型为巨石应用，集成所有组件、工具及应用，来降低研发流程的复杂度及提升业务模块复用率，从而达成提效的目的。
+
+下面是构思的分层架构图，简单分为**基础支撑**、**业务支撑**部分，来支撑后续应用的改造及需求研发。
+
+![main.png](main.png)
+
+**基础支撑** 主要包含通用、抽象的工具集、UI组件以及项目底层的规范和统一的文档输出。
+
+**业务支撑** 则是更进一步，将安装更细粒度的业务模块，引用和复用基础支撑，再结合API数据，来产出业务数据模型、业务模型来支撑应用。
+
+下面是一个示例图，描述它们之间的关系。
+
+![component.png](component.png)
+
+这样的 monorepo 架构当然也有它的缺点，但思考后可以通过加强规范及审查流程来避免问题，针对公司内没有使用 gitlab，无法合并前 hooks的场景，要进行流程强化，合并前强制进行本地的脚本进行检查。
+