先聊聊曾经
好像从从业开始之后,每每向前辈请教代码怎么写,前辈总是云淡风清的说一句,先建库建表,然后对着建的表写实体类,然后用表和实体类写DAO层,然后跟着写service层,最后写controller。这样把增删改查四大方法写出来就可以了!然后页面(View)看看需要做什么操作或者查询什么数据,对应着controller里面写方法,然后参数加工一个传到service层,然后在service层里面调别的service,dao来操作数据库,完成业务逻辑。这也就是大家常说的,工作就是ctrl+c , ctrl+v 天天增删改查
开始造作
这段时间小刀在工作时偶然看到了领域模型驱动(圈起来,要考的重点),感觉为小刀的思考和学习思路提供了一个新选择。和上一段说的分层不太一样,新选择指引我们从业务入手,先提炼出一些关键概念点,然后划分出基础支持和业务数据。
如网站常用的登录,最简单的设计就是一张user表,里面存账号密码和手机号,这样手机号/账号密码登录都能支持。要是哪天来个微信登录呢?这怎么存?加个字段?再来个QQ登录?再来个微博登录?
程序员界有名话说:没有什么问题是加张中间表解决不了的,如果有,那就加两张,对上面的用户设计,有的小伙伴已经给出了较好的答案,对,加张中间表,账号表account ,一个user(用户)对应多个account(账号
换个思路再想想
前段时间设计用户中心时,小刀也确确实实是按上面的思路走的,但是走着走着就感觉还是很模糊,然后小刀就尝试换个思路想,如上所述:
最开始在设计时,一想都在想着,遇到业务场景时要对哪个做什么操作(此处要提一下我前任领导常说的一句说,不要脱离业务讨论技术方案)但是现在我们要往上走一步,不要说对表执行什么什么操作了,要说对表代表的实体做什么操作。如:有新客注册时,我们要先在 账号中添加一条账号,然后提取基本信息添加到用户中。这样我们就得到了两个关键概念,以后的讨论和描述都围绕着这两个点进行。
有的小伙伴估计要说了,这和用表讨论没什么区别啊,对,是没什么区别,但去掉表,就是一个新的思路。
就以上说的两个关键点而言,以前没有这个划分概念的时候,觉得这不都是数据库表嘛,都属于用户这一块的。小刀和大家一起来按下面这两种思考方式走一下:
一, 用户是基础数据,账号是业务数据
用户这些数据,换个系统也能用,但是账号就不一样了,上面可能有余额,积分这些和业务强相关的东东,换个地方就不好使了
二,用户和账号都是基础数据
用户是用户的基本信息,账号只代码着用这里面的手机号/用户名密码能登录这个系统,真正的业务数据要单独建个表和账号关联,如管理员表,如普通用户表
最后说两句
孙子兵法有言:夫未战而庙算胜者,得算多也;未战而庙算不胜者,得算少也。在写代码之前,如果不思考好这些东西,就会发现越写bug越多,所以小伙伴们可以尝试从现在自己负责的模块入手,思考下如何提炼关键点,如何划分基础数据和业务数据。
下期预告:拥抱DDD,新的代码组合方式