前几日，去临海给用户做信息化应用培训。培训工作如何开展，思虑再三，如果只是按照功能模块进行讲解，会略显枯燥乏味，因此想通过业务场景化的方式把多个功能模块进行串联,加深培训效果。最后发现各个模块之间的关联性不强，采取通过具体的业务场景，说明帮助用户在实际过程中解决了哪些问题，来引出相关功能模块的说明。
通过以上的思考，引出了一个问题，如果平台软件设计也采用业务场景化的模式，会不会更好？
举一个业务场景的例子，一个保安需要在大楼每层进行巡逻，在大楼各处设置了多个门禁的巡查点，通过各个巡查点的打卡，来确定一次完整的巡逻记录。
先确定该场景所涉及到的各个元素：
门禁设备、打卡使用的卡片、人员信息、大楼信息
在平台中会涉及到的一些最基本操作：
门禁设备的添加、卡片添加、人员信息添加、大楼打卡点信息添加、门禁设备与大楼打卡点绑定、人员和卡片绑定、巡逻路线计划添加
如果采用业务场景化的设计方式，那么这些功能都会被打包进一个模块，暂时叫保安巡逻模块吧。
现有的平台设计方式，可能会采用以下方式：
门禁设备的添加、卡片添加、人员添加、大楼巡查点添加分别抽象为一个模块，在一个业务场景的配置过程中，需要在多个模块之间进行多次的跳转操作。
在编程上相同的代码会进行提取，抽象为一个公共函数，但是应用在平台功能设计上，真的同样适用吗？是否还是允许一些冗余界面的出现，能够更加方便用户理解和操作平台的功能呢？
一个功能的实现，怎么样算好？
同样以保安巡逻功能为例，通过分析我们知道，实现功能最少需要七步的配置操作，那么如果在平台上实际配置的操作超过七步，那么这个功能实现的就不算最好。
配置功能和业务功能是否需要划分为二个模块?
一般情况下，对于用户展现和实际使用都仅限于业务功能模块，所以配置功能对于用户是不可见的，因此配置功能和业务功能是需要区分为二个不同的模块，但是也需要考虑到配置频率，如果某些配置需要每天或则每周配置，那么这些配置操作应该提取出来合并进业务功能模块。
网友评论