开场
哈喽，大家好，我是一名科班出身的程序猿，目前从事前端方向的开发工作。记得我从学校毕业刚出道的时候，对于项目架构这个词汇很陌生，根本不清楚架构是什么，但是后来随着开发工作的技术积累，以及编程思维的沉淀，慢慢懂了什么叫架构设计，这样正是今天我要分享的主题，那么接下来大家就来跟着我的脚步，回顾一下我自己对前端项目架构设计和模块规划的理解。
关于本人
有着6年的一线开发经验的程序猿，主要从事移动开发和前端开发工作，掌握的开发方向有：iOS开发、Android开发、微信小程序开发、Flutter开发、Vue.js开发。
同时本人也经营和维护者自己的名片，公众号和微博，对我感兴趣的可以搜索名字添加一下（征婚的除外），哈哈。
什么是架构？
架构就是事物之间的宏观联系，主要分为以上三个方面：
1、事物
一切需要理解的东西，不限于软件
软件只是这些事物的缩微模型
2、宏观
宏观调整很难，影响很大，成本很高
不要让细节淹没了你的思维
3、联系
如何分工 —— 内聚
如何协作 —— 耦合
架构的三个层面
1、业务架构
目标组织有哪些业务？
这些业务之间的联系是什么？
2、组织架构
目标组织分成哪些部门？
各部门的分工是怎样的？
这些部门之间如何协作？
3、系统架构
为了支持业务运行，有哪些IT系统？
这些IT系统之间的联系是什么？
三种架构之间的联系
市场环境—>业务架构—>组织架构—>系统架构—>竞争力
架构的“形状”就是知识的边界
1.我们把知识的边界叫做领域
准确理解知识，是设计好架构的前提
以业务领域为驱动进行设计，才能确保系统紧跟上业务需求的演化
2、领域是架构对齐的基准
要想架构稳定，就要把它对齐到知识领域
架构是否合理，要靠领域知识来判断
3、这就是 Domain-Driven Design
为什么应用会腐化？
1、业务需求不断增加（业务问题）
用户有了新需求
我们有了新创意
对手出了新功能
2、旧功能的残留不断堆叠（混合问题）
不能删（不知道有没有用）
不敢删（不知道删了会怎样）
删不动（与其它功能有千丝万缕的联系）
3、技术环境变化（技术问题）
比如IE退出历史舞台
用户体验方面
1、质量差（可维护性）
BUG多，修复慢
特性老化，跟不上时代
2、速度慢（性能）
启动慢/首屏加载慢
日常操作慢
不要被数字指标骗了，要关注用户的感知性能
Core Web Vitals评分机制
LCP - Largest Contentful Paint
最大内容绘制
体现加载速度
FID - First Input Delay
首次输入延迟
体现可交互性
CLS - Cumulative Layout Shift
累计布局偏移
体现视觉稳定性
研发方面
1、迭代周期太长（性能-开发阶段）
构建太慢
测试太慢
部署太慢
2、牵一发而动全身（可维护性）
不知道要改哪里
改完之后不知道会影响到哪里
3、统一性、一致性太差（概念一致性）
有的地方用红色表示警告，有的地方用黄色
同一个控件出现在多个项目中时，外观或行为都不一样
项目管理方面
1、琐碎需求太多（灵活性）
改个颜色吧，改个文字吧，改个布局吧
这不完全是产品经理的锅
2、沟通/协作成本高（可维护性）
容易出现合并冲突
跨团队的API管理成本高
分工不清晰，导致难以专注，甚至扯皮
3、人事风险高
高手不好招，新手不好带
我们把这些总结为对架构的需求
1、工件体积要小，要支持分块加载
2、可维护性要好，新增和修改都要方便
架构组件之间的耦合要小、隔离要严格，要局部化
架构组件职责要明确，这样分工才能明确
架构组件要能独立构建、独立发布
3、要区分高手和新手的职责，做到人尽其才
4、要管理好各级可复用资产
我们的武器库
1、工作空间
有共同的依赖包
通常彼此依赖
2、项目
发布周期/载体相同
由同一个项目组维护
3、模块
隐藏私有API
可以独立加载
如何进行纵向切分
1、按照业务领域划分
必须有业务专家参与，甚至要由他们主导
如果某些操作是围绕同一个业务概念进行的，就划到同一个子域
如果不知道该怎么做，可以借助DDD方法论进行划分
2、明确边界
特性模块都做成惰性加载的
特性模块不应导出组件，它只应该提供路由
路由树应该和领域树同构
3、控制依赖
不同的子树之间不要相互依赖
架构设计过程
1.对业务知识进行建模
业务专家 架构师
2.根据知识的边界，划分子域
业务专家 架构师
3.映射到系统架构
架构师 Tech Lead
它解决了什么问题？
1、工件体积要小，要支持分块加载
特性模块的惰性加载机制
2、可维护性要好，新增和修改都方便
特性模块的所有组件是私有的，所有影响都局限在小范围
3、架构组件之间的耦合要小、隔离要严格，要局部化
禁止特性模块的跨子树依赖
4、架构组织职责要明确，这样分工才能明确
按业务领域划分，把业务知识局部化
如何做好横向切分
1、做好版本管理
严格遵循语义化版本规范
2、做好关注点分离
分离技术问题和业务问题
分离简单问题和复杂问题
3、组件库不要局限于源码库的形式
可以是传统的源码库
也可以是独立发布的应用（Web Components库）
组件库的最佳实践
1、私有是通例，公开是特例
如非必要，不要公开
公开的就是对别人的承诺
给别人承诺容易，收回承诺难
2、区分业务无关组件库与业务相关组件库
前者只解决技术问题，不涉及业务概念
后者在前者的基础上封装，只解决业务问题
3、拆成多个小型部件
比如要用在表单中的编辑器，应该拆成一个表单无关的编辑器和一个控件访问器指令，而不是直接做一个支持表单的编辑器
开发团队的合理分工
1、架构师
全栈：业务 前端 后端，关注全局，未必专精
2、技术专家
专精一门，解决核心技术问题，多团队共享或外聘
3、资深前端工程师
熟悉业务，精于前端，了解后端
4、资深后端工程师
熟悉业务，精于后端，了解前端
5、新手工程师
选择自己喜欢的领域，可轮换角色
结束语
通过以上几个部分的剖析，让大家看到了项目的架构设计与模块规划的大概体系，通过上述的注意点可以在以后的开发中运用，做到整体把握。谢谢大家的聆听，请大家认准“三掌柜”这个唯一表示，欢迎线下交流！谢谢！
