如何设计一个糅合系统

首先，关于这篇文章为何取名为设计一个糅合系统的设计，所谓的糅合系统，是指这个系统的用户群体没有那么纯粹，比如，是一个既有c端用户，又有b端用户的使用场景的系统，起初在设计这样一个系统之初，我思考过这样的一个系统会有几个问题：

逻辑混杂，到时候会出现这个c端是这个样子的，b端为了兼容而妥协，折中出来的并不是一个好的方案，对两类用户来说都不够简洁。
if/else糅合的代码可理解性比较差，随着迭代的推进，后续会越来越来维护。
b端更加注重功能体验，他们要的是功能能不能满足他日常运营，而且不同类的b其功能是不同的，用户端更加注重操作体验体验是否好，当然b端也注重操作体验，但相对没c端这么匠心。
不同的b端可能需要的主体风格不同，是考虑一个b一套代码，还是一套代码配置不同的b，还是一套b的框架下组合不同的工具。
分离/b-part/c-part之后，如何复用公共逻辑，减少重复开发工作，公共逻辑包括哪些，下层的规则是什么，该放在何处。
假如让一个新手加入进来，他怎么快速找到相应的业务的代码逻辑在何处，如何新增，修改代码已实现需求。

基于以上这些点的思考，我首先走出了一个设计的雏形。

首先，我们先站在上帝视角来看一看，一个用户是如何和我们的系统打交道的。第一个我们关心的是一个三要素：

是谁？来干什么？干什么后去哪里？我们可以用一个故事的方式来描述几个这样的案例。

以上的场景，我们均可以从里面抛出【是谁，干啥，去哪】，这其实就是我要说的意图2.0，。

故事2是一个特例，实际上，不知道什么干什么也是一种干什么，不知道去哪也是一种去哪，不知道是谁也是一种是谁。

就是要确定进入系统的用户身份，是b端的用户，还是c端的用户，一旦确定了身份，这个应该是全局可知的

就是要确定是谁之后的事了，就像大家去政府办事一样，人家首先明确你是谁，然后在问你来干啥，你干啥是不是得交出一些办事的凭据来，事情的id，通过这个事情的id就对应到了不同的功能。

首先每个功能有其内部的流转流程，它自己知道哪一步该去哪？但是：

那么他下一步将走到哪里呢？这个是这个故事里的人的是，应该把选择的权利交给他。

要确定用户身份，我设计需要一个用户管理模块，它具备的能力有：

最终是为了确定用户身份。

我们去银行我们会带上银行卡，我们去买菜会带上菜篮子，我们去做火车会带着车票，我们去考试会带上准考证….我们都会遵守一些既定的事情的协议。

我们去买什么东西会写一个清单，如是：

所以，用户来干什么，都是一系列的动作，做这些动作需要一个清单才知道具体怎么做，交给谁做很容易，我们就想到了路由。

路由器就是一个配置表，表述的事情是，xx:buy&item1=”南瓜”&item2=”瓜子1公斤”