【架构师（第一篇）】整体需求分析和架构设计 |
您所在的位置：网站首页 › openapi架构设计 › 【架构师（第一篇）】整体需求分析和架构设计 |
【架构师（第一篇）】整体需求分析和架构设计
|
需求分析和架构设计
脱离业务的架构就是耍流氓。架构师必须要深入理解需求、参与需求、看透需求背后的业务本质。 👉👉 需求文档 👉👉 项目在线体验 👉👉 学生的学习笔记 👉👉 代码仓库 产品研发流程项目主要分为 三个 大端： 编辑器端 H5作品展示端 管理端除 H5 端外，均采用前后端分离模式进行开发。此外，为提 H5 作品展示端的渲染性能，采用服务端渲染。 模块受众： 编辑器端：设计师及其他用户 H5 端：作品受众、普通用户 管理端：网站管理人员模块职责简述： 编辑器端制作发布作品、保存模板，并能查看作品的浏览、分享等数据，管理账户作品及模板等 H5 端用于显示成品作品，使用服务端渲染提高性能与用户体验，收集浏览及分享数据，发送到统计服务端 管理端管理作品，紧急下架，编辑器端用户管理，查看网站所有数据（用户数、浏览量、作品数量等）其他重要部分： 所有数据共用一个数据库 开发一个属于该项目的脚手架，提高开发效率 自研自定义事件统计服务，让项目闭环使日后有方向地让业务增长 开发一个属于本项目的组件库，提高开发效率，为了创作作品后的效果和 H5 端显示的效果一致，编辑器端及 H5 作品展示端都使用该组件库 确定需要哪些项目B端和编辑器，做前后端分离 biz-editer-fe biz-editer-serverH5适合做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 端来判断数据流转关系图 |
【本文地址】
今日新闻 |
推荐新闻 |