产品 = 技术 + 业务，通过技术手段实现业务需求，并用工程的手段不断迭代，这就是产品产生和迭代的过程。业务最开始都是来源于现实，通过一系列的抽象，把涉及到的概念转换成数据模型，然后把业务流程映射成一系列数据变动的过程，最终在ui上展示出来，这是软件产生的过程。其中涉及到3个要素，数据模型、架构、ui。
我们在做的教育方面和云课堂方面的业务也是如此，无非是因为组织的庞大，职责分离的更细致而已，上面的软件3要素依然适用。我们从数据模型、架构、ui三个方面来分析一下我们的产品和业务。
数据模型
想一下现实中教育机构从学员报名到老师备课上课一系列的过程：学生看到课程的介绍，购买课程，老师为课程根据时间、地点等安排一系列的课次，每次课都需要备课，需要用到的课件、测试题、本讲涉及到的一些资料等。
如图所示，这是一个简化的数据模型图，但是涵盖了从下单，到上课涉及到的一系列业务上的概念。
我们的云课堂就是涉及到课程下的某一个课次的一个教学过程中的各种业务概念，比如测试题、课件、本讲资料、课堂花园、纪律树、奖章榜等，
架构
整个业务过程分成了好几块，不同的部门来维护自己的那部分，
如图，教师、学员、订单、课程等核心的数据由基础平台组维护，并且向外暴露了api，每个课程的各个课次上课相关业务由云课堂组维护，而课件是另一个组维护。
单说云课堂这边，老师端和上课用的客户端是分开的，教师端app和对应的服务端是一个小组来维护，上课用的ITS的客户端和服务端是一个小组维护。
整个数据模型和业务过程通过合理的划分，对应到了不同的业务组，之间通过api来耦合，只要大的结构不改，各种细致的数据模型和业务过程可以自己扩展，比如我们ITS扩展出的纪律树、奖章榜、课堂花园等，都是与基础平台无关的，可以独立扩展的部分。
所以，我们做测试模拟业务过程的时候，需要使用基础平台组做的后台系统去添加课程、课次，生成模拟学员、上传本讲资料，通过课件组的后台去上传课次的课件等。
这是公司的业务和部门的架构，涉及到技术的架构，各个部门和组都不同，云课堂这边是 mysql + SpringBoot / Vuex + Vue + Electron
ui
同样的数据模型和业务过程，不同的ui也会给人不同的感觉，根据面向的对象以及产品特点的不同，对应的ui风格可能差距很大。
只谈我们的ITS，也就是上课用的客户端这部分，因为面向的学生年龄较小，所以ui风格更活泼一些、颜色也更鲜艳、动画和交互效果比较多，同时整个产品因为部分代替了黑板，所以登录以后的功能菜单和各种功能都可以折叠成可拖动的小窗口，并且可以隐藏或关闭。
总结
分析了数据模型、业务和公司架构、ui风格之后，对公司所做的业务以及业务对应到公司架构的部门划分，和产品面向的对象和扩展点，以及整个系统的全貌等都有了一些更深入的认识。
我们公司虽然把整个业务过程拆的很细，但是总体来看还是挺清晰的。
网友评论