KK 架构训练营 - Week3

1、从解决方案架构的视角，把自己之前作业的内容，稍微细化一下。如果内容很多，可以选择其中的一个点，进行深入作业。

2、从系统架构视角，选择 4+1 视图中的部分内容，深入优化一下作业中的某一项。

3、思考自己的工作中，使用的设计文档跟这里讲的有什么差别。

本次课程听着觉得信息略大, 想想自己目前可能也就 P6 水准, 斗胆按自己理解写一下作业, 哈哈.

按课程所述, 4A 架构包括业务架构(BA), 信息架构(IA), 应用架构(AA), 技术架构(TA). 其关系如下:

按群友提供的“大白话”版本, 如下图:

选择作业的对象为部门于今年 10 月份中标的某企业的某业务系统. 以该系统为分析对象.

• 业务架构

• 动机: 甲方在使用此前一方的标准化产品, 在使用中, 甲方的用户量较大, 派发任务, 选择对象较多, 单次任务可以选到 2w+的人作为执行方, 系统卡顿, 而此前建设方为某三方公司, 该公司不愿意为甲方定制调整逻辑. 此前我司承接了甲方的平台总集成系统建设, 故此次希望我方能更进一步, 接下来这一块业务, 并强调新建设的系统需要具备一定的性能; 公司的领导也希望通过本次机会, 打造通用的 xx 产品, 后续以此为典型案例, 推广给更多用户. 项目拟于 12 月初上线, 替换目前在用的系统.

• 组织:

• 前期工作: 总体组(负责招投标工作) + 市场人员/部门领导(负责商务部分)

• 产品设计: 产品组

• 产品实现: 前端组(含 APP 客户端研发) + 后端组 + 数据采集组 + 测试组

• 行为:

• 产品人员设计与用户沟通, 设计原型, 与用户方的负责人确认, 参考此前三方的某系统设计功能, 前后端基于用户重点提出的优化点进行交互层面的优化/业务流程设计的优化;

• 前后端及采集组, 就产品涉及的技术点进行任务拆解, 方案调研;

• 测试组基于设计的功能编写测试用例, 待研发联调的差不多时, 进行功能验证, 执行 QA 相关工作.

• 信息系统架构

• 数据

• 用户, 按角色可以分四类, 如 管理员(A) / 一级负责人(B) / 二级负责人(C) / 任务执行人(D)

• 任务, 包含任务数据, 任务完成情况数据, 消息数据等

• 应用

• Web 端

• APP 端, 包含安卓及 iOS 端的 APP

• 技术架构

• 前端组, Web 端采用 VUE, 基于此前已有的业务脚手架构建; APP 端由于需要跨端, 且研发人员有限, 对 VUE 技术栈相对更熟悉, 且其需主要集中在写业务代码, 故采用 uni-app 构建;

• 后端组, 基于此前部门已有的基础设施, 故采用基于 Spring Cloud Netflix 体系构建后端业务微服务. 本次的用户, 都允许重名, 通过手机号注册, 且其组织架构与权限系统此前的组织方式完全不同, 故考虑扩展当前的权限系统服务, 添加相关的接口, 包括按手机号注册接口(返回用户 ID)/手机登录接口/按用户 ID 更新信息接口等等. 针对用户核心的任务下发场景, 考虑基于消息队列的方式, 优化流程; 针对用户提出的需要即时消息提示的请求, 后端实现需对接微信服务号及三方的 APP 消息平台等.

• 采集组, 针对业务需要的自动化功能, 做是否能实现调研等.

• 此前后端的设计文档大概如下:

【腾讯文档】WP系统后端设计方案

• 差别:

• 项目用的设计文档

具体的设计方案会关注实现细节, 相关的文档中, 需要研发人员准确写出微服务调用关系, 数据模型(数据表字段等), 以避免其在实现代码之时走弯路; 具体的设计文档不会拘泥于文档格式, 主要方便沟通, 服务于团队内部等;

• 本课讲的相关文档

看问题的角度更高, 不拘泥于实现细节. 另外, 如采用类似于 CMMI 相关的软件管理体系(多数是应付相关检查等等), 需要写出来各种各样的设计文档, 其内容是更加复杂.