本文会分享一个我在实际工作中遇到的案例，从最开始的需求分析到项目搭建，以及最后落地的架构的整个过程。最终实现的效果是使用mono-repo实现了跨项目的组件共享。在本文中你可以看到：
从接到需求到深入分析并构建架构的整个思考过程。
mono-repo的简单介绍。
mono-repo适用的场景分析。
产出一个可以跨项目共享组件的项目架构。
本文产出的架构模板已经上传到GitHub，如果你刚好需要一个mono-repo + react的模板，直接clone下来吧：https://github.com/dennis-jiang/mono-repo-demo
需求 需求概况是这么个情况，我还是在那家外企供职，不久前我们接到一个需求：要给外国的政府部门或者他的代理机构开发一个可以缴纳水电费，顺便还能卖卖可乐的网站。主要使用场景是市政厅之类的地方，类似这个样子：
这张图是我在网上随便找的某银行的图片，跟我们使用场景有点类似。他有个自助的ATM机，远处还有人工柜台。我们也会有自助机器，另外也会有人工柜台，这两个地方都可以交水电费，汽车罚款什么的，唯一有个区别是人工那里除了交各种账单，还可能会卖点东西，比如口渴了买个可乐，烟瘾犯了来包中华。
需求分析上面只是个概况，要做下来还有很多东西需要细化，柜员使用的功能和客户自助使用的功能看起来差不多，细想下来区别还真不少：
无论是交账单还是卖可乐，我们都可以将它视为一个商品，既然卖商品那肯定有上架和下架的功能，也就是商品管理，这个肯定只能做在柜员端。
市政厅人员众多，也会有上下级关系，普通柜员可能没有权限上/下架，他可能只有售卖权限，上/下架可能需要经理才能操作，这意味着柜员界面还需要权限管理。
权限管理的基础肯定是用户管理，所以柜员界面需要做登陆和注册。
客户自助界面只能交账单不能卖可乐很好理解，因为是自助机，旁边无人值守，如果摆几瓶可乐，他可能会拿了可乐不付钱。
那客户自助交水电费需要登陆吗？不需要！跟国内差不多，只需要输入卡号和姓名等基本信息就可以查询到账单，然后线上信用卡就付了。所以客户界面不需要登陆和用户管理。
从上面这几点分析我们可以看出，柜员界面会多很多功能，包括商品管理，用户管理，权限管理等，而客户自助界面只能交账单，其他功能都没有。
原型设计基于上面几点分析，我们的设计师很快设计了两个界面的原型。
这个是柜员界面的：
柜员界面看起来也很清爽，上面一个头部，左上角显示了当前机构的名称，右上角显示了当前用户的名字和设置入口。登陆/登出相关功能点击用户名可以看到，商品管理，用户管理需要点击设置按钮进行跳转。
这个是客户自助界面的：
这个是客户界面的，看起来基本是一样的，只是少了用户和设置那一块，卖的东西少了可乐，只能交账单。
技术现在需求基本已经理清楚了，下面就该我们技术出马了，进行技术选型和架构落地。
一个站点还是两个站点？首先我们需要考虑的一个问题就是，柜员界面和客户界面是做在一个网站里面，还是单独做两个网站？因为两个界面高度相似，所以我们完全可以做在一起，在客户自助界面隐藏掉右上角的用户和设置就行了。
但是这里面其实还隐藏着一个问题：柜员界面是需要登陆的，所以他的入口其实是登陆页；客户界面不需要登陆，他的入口应该直接就是售卖页。如果将他们做在一起，因为不知道是柜员使用还是客户使用，所以入口只能都是登录页，柜员直接登陆进入售卖页，对于客户可以单独加一个“客户自助入口”让他进入客户的售卖页面。但是这样用户体验不好，客户本来不需要登陆的，你给他看一个登录页可能会造成困惑，可能需要频繁求教工作人员才知道怎么用，会降低整体的工作效率，所以产品经理并不接受这个，要求客户一进来就需要看到客户的售卖页面。