需求分析和架构设计

脱离业务的架构就是耍流氓。架构师必须要深入理解需求、参与需求、看透需求背后的业务本质。

👉👉 需求文档

👉👉 项目在线体验

👉👉 学生的学习笔记

👉👉 代码仓库

产品研发流程

以架构师思维分析需求

浅层需求

用户信息
- 登录（短信验证码）
- 注册
- 获取用户信息
作品
- 创建
- 保存
- 发布
- 获取作品列表
- 获取作品信息
模板
- 模板列表
- 使用模板创建

深度需求

作品的管理
- 删除和恢复
- 转赠
- 复制
作品的统计
- 分渠道统计
- 查看统计结果
作品的发布
- URL不能变
- 支持多渠道
作品的分享
- H5分享
后台管理
- 数据统计
- 作品管理，能快速下线作品，防止有违规内容
- 用户管理，能快速冻结用户，防止有违规用户
- 模板管理，能控制哪些模块展示，哪些不展示

整体架构设计

项目主要分为三个大端：

编辑器端
H5作品展示端
管理端

除 H5 端外，均采用前后端分离模式进行开发。此外，为提 H5 作品展示端的渲染性能，采用服务端渲染。

模块受众：

编辑器端：设计师及其他用户
H5 端：作品受众、普通用户
管理端：网站管理人员

模块职责简述：

编辑器端制作发布作品、保存模板，并能查看作品的浏览、分享等数据，管理账户作品及模板等
H5 端用于显示成品作品，使用服务端渲染提高性能与用户体验，收集浏览及分享数据，发送到统计服务端
管理端管理作品，紧急下架，编辑器端用户管理，查看网站所有数据（用户数、浏览量、作品数量等）

其他重要部分：

所有数据共用一个数据库
开发一个属于该项目的脚手架，提高开发效率
自研自定义事件统计服务，让项目闭环使日后有方向地让业务增长
开发一个属于本项目的组件库，提高开发效率，为了创作作品后的效果和 H5 端显示的效果一致，编辑器端及 H5 作品展示端都使用该组件库

确定需要哪些项目

B端和编辑器，做前后端分离

biz-editer-fe
biz-editer-server

H5适合做SSR，因为要考虑性能

h5-server

管理后台，做前端分析

admin-fe
admin-server

业务组件库

H5 端和 b 端画布的渲染逻辑是一样的，所以使用独立的组件库，达到复用的效果。

统计服务OpenAPI

PV，UV 使用百度统计等第三方服务，自定义事件需要自研。

各个项目之间的关系

数据结构设计

编辑器原型

数据结构设计

基本思路：

每个组件尽量符合 vnode 规范
用数组来组织数据（有序）
尽量使用引用关系，不用冗余

  {
    work: { // 每一个作品
      title: '作品标题',
      setting: {}, // 一些可能的配置项 扩展性保证
      props: {}, // 页面的一些设置 扩展性保证
      // 组件(数组,可以排序) 
      // 单个 node 要符合常见的 vnode 格式
      components: [
        {
          id: '1',
          name: '文本1',
          tag: 'text',
          attrs: {
            fontSize: '20px',
          },
          children: ['文本1'],
        },
        {
          id: '2',
          name: '图片1',
          tag: 'image',
          attrs: {
            src: 'xxx.png',
            width: '120px',
          },
          children: null,
        },
      ],
      //当前选中的组件id
      activeComponentId: 'xxx'
    },
  },

数据流转

核心:B 端，C 端，管理后台，公用一个数据库

创建作品:初始化一个 JSON 数据
保存作品:修改 JSON 数据
发布作品:修改一个标记，仅此而已
C 端浏览作品:获取 JSON 数据，SSR 渲染页面
屏蔽作品：修改一个标记，C 端来判断

数据流转关系图

【架构师（第一篇）】整体需求分析和架构设计