首先,关于这篇文章为何取名为设计一个糅合系统的设计,所谓的糅合系统,是指这个系统的用户群体没有那么纯粹,比如,是一个既有c端用户,又有b端用户的使用场景的系统,起初在设计这样一个系统之初,我思考过这样的一个系统会有几个问题:
基于以上这些点的思考,我首先走出了一个设计的雏形。
首先,我们先站在上帝视角来看一看,一个用户是如何和我们的系统打交道的。第一个我们关心的是一个三要素:
是谁?来干什么?干什么后去哪里?我们可以用一个故事的方式来描述几个这样的案例。
以上的场景,我们均可以从里面抛出【是谁,干啥,去哪】,这其实就是我要说的意图2.0,。
故事2是一个特例,实际上,不知道什么干什么也是一种干什么,不知道去哪也是一种去哪,不知道是谁也是一种是谁。
就是要确定进入系统的用户身份,是b端的用户,还是c端的用户,一旦确定了身份,这个应该是全局可知的
就是要确定是谁之后的事了,就像大家去政府办事一样,人家首先明确你是谁,然后在问你来干啥,你干啥是不是得交出一些办事的凭据来,事情的id,通过这个事情的id就对应到了不同的功能。
首先每个功能有其内部的流转流程,它自己知道哪一步该去哪?但是:
那么他下一步将走到哪里呢?这个是这个故事里的人的是,应该把选择的权利交给他。
要确定用户身份,我设计需要一个用户管理模块,它具备的能力有:
最终是为了确定用户身份。
我们去银行我们会带上银行卡,我们去买菜会带上菜篮子,我们去做火车会带着车票,我们去考试会带上准考证….我们都会遵守一些既定的事情的协议。
我们去买什么东西会写一个清单,如是:
所以,用户来干什么,都是一系列的动作,做这些动作需要一个清单才知道具体怎么做,交给谁做很容易,我们就想到了路由。
路由器就是一个配置表,表述的事情是,xx:buy&item1=”南瓜”&item2=”瓜子1公斤”
功能 | 参数 | realPath | |
---|---|---|---|
xx:c-buy | c端买东西 | item1=”南瓜1斤”&item2=”瓜子1公斤” | pages/c-buy/index |
xx:b-buy | b端买东西 | item3=”南瓜1斤”&item4=”瓜子1公斤” | pages/b-buy/index |
功能需要是一个比较内聚的概念,他可以包含一系列的动作,有自己内部的流转流程,更具数据的状态及用户的操作来驱动页面UI 的展示,即:
功能= 数据 + action + UI
功能,他有依赖底层的一些服务,及一些公共的工具函数。
那么,基础服务包括哪些呢?
经过上面的分析,我们不能达成一个从上倒下依赖的三层架构模式:
路由层的作用是找到三要素【是谁,干啥,完事之后去哪】
拦截器是干啥的,上面已经提到,是找出三要素,找到之后如果发现非法入侵,就会把他路由到非法页。
功能层是解决干啥的。
功能才的Action是干啥的,是处理用户的的各种动作的,包含:
这样的一些操作都的会引起数据变化,进而导致UI发生改变。UI的实现可以原生,可以web,
基础层是帮助功能层很好的完成干啥的。
一个好的系统肯定是需要可观测性的,需要trace用户的行为,包含
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。