演讲稿：项目的架构设计与模块规划

开场

哈喽，大家好，我是一名科班出身的程序猿，目前从事前端方向的开发工作。记得我从学校毕业刚出道的时候，对于项目架构这个词汇很陌生，根本不清楚架构是什么，但是后来随着开发工作的技术积累，以及编程思维的沉淀，慢慢懂了什么叫架构设计，这样正是今天我要分享的主题，那么接下来大家就来跟着我的脚步，回顾一下我自己对前端项目架构设计和模块规划的理解。

关于本人

有着 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、新手工程师

选择自己喜欢的领域，可轮换角色

结束语

通过以上几个部分的剖析，让大家看到了项目的架构设计与模块规划的大概体系，通过上述的注意点可以在以后的开发中运用，做到整体把握。谢谢大家的聆听，请大家认准“三掌柜”这个唯一标识，版权归 王志成--专家级咨询师所有。欢迎线下交流！谢谢！

注意：以上内容都是按照演讲稿 PPT 的形式来呈现，每个大标题都代表一页 PPT 的内容，看官请注意！