需求分析和架构设计

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

👉👉 需求文档

👉👉 项目在线体验

👉👉 学生的学习笔记

👉👉 代码仓库

产品研发流程

以架构师思维分析需求

浅层需求

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

深度需求

• 作品的管理
  • 删除和恢复
  • 转赠
  • 复制
• 作品的统计
  • 分渠道统计
  • 查看统计结果
• 作品的发布
  • 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 端来判断

数据流转关系图