做业务的开发们,几乎都有一个做架构的心,好的业务开发者不仅要能做好业务,更要能做好业务架构。在现实中我们总会遇到大大小小的需求,那我们应该怎么在满足业务的同时又能作出很好的技术设计呢。 1. 什么是好的技术设计好的技术设计应该很清楚的表达了:
2. 要解决的问题要解决的问题,其实就是需求是什么。很多人觉得提需求是产品经理的事情,和开发没有什么关系,开发人员只要写代码就可以了,实则不然。产品经理提出的需求和开发清楚理解要解决的问题,还是有一段距离的。 最简单的产品经理提出需求:为用户提供一个登录界面,可以在APP和微信上使用,同时能够防止机器人自动注册。 2.1 拆解产品需求
一般产品经理提出的需求在技术人员来看都缺少足够的细节,这种时候需要针对产品需求进行拆解,将需求拆解为更小的需求,确认其中的细节。例如针对登录界面的需求就可以划分为用户登录界面的基本逻辑和防机器人自动登录/注册的两个子需求。 2.2 挖掘潜在需求针对上面的两个子需求,我们继续探究一下其中的潜在需求:
这其中的很多细节都是隐含的,有些是产品经理自己能想到的,有些是产品经理模糊有个印象的,有些可能压根就没有想到的,这时候需要技术人员一一确认细节,补充丰富需求。 2.3 未来可能扩展的需求针对用户登录这个需求,未来可能需要,在用户登录的时候将用户的登录上下文参数记录下来,如用户登录ip、登录平台、微信登录时的id信息等,并将这些作为用户的特征信息记录下来并广播出去,供其他业务模块做逻辑判断的条件之一。 比如,未来可能针对微信端登录的用户,给这部分用户发抵用券等行为。 2.4 确定需求拆解并细化了产品需求,但并不是所有的需求都要在这一次实现,需要最后跟产品确认这一次需要实现的需求。
确认了需求,我们的技术设计也就完成了一半。 这样说来一些技术人员可能会觉得有些夸张,但实际工作中,不同的需求真的可能完全改变技术方案,——比如在关于微信的一点思考文中,提到Slack和微信关于聊天记录的不同而导致技术上实现成本大增,且实现重点都会发生很大的变化。 为了便于后面讨论,我们例子中的产品需求定位下来只提供用户登录,和短信验证码验证。 3. 解决方案3.1 业务领域的划分现在的技术大趋势是采用服务化的方式实现业务,正确划分业务领域也是实现服务化基础之一。
业务领域划分,首先需要从需求角度来分析。如例子中的需求主要包含用户登录和短信验证码两个方式。
实际项目中划分业务领域不会像例子中那么界线分明,项目中的业务领域相互有包含关系,业务边界有交叉甚至有相似之处,但从业务和系统的角度深入分析,才能慢慢厘清其中的关系。 3.2 数据模型业务领域模型和数据模型共同构成了系统业务模型。数据模型是数据库系统的核心和基础,在设计中使用E-R图的方式来展示数据模型。 业务模型抽象出来之后,我们的数据库表的设计也就基本有出来了,只要再根据业务需求进行合理的字段冗余和索引设计就形成了基本的数据表。为了应对高并发需求,数据库会进行分库分表的处理;前文说道的业务领域划分,在数据表上就是垂直分表的体现。 3.3 服务关系厘清了业务领域和业务模型,各服务之间的依赖关系也就非常清晰了。在本文的例子里,用户登录服务直接依赖短信验证服务。在技术设计中,不单单需要厘清本次需求涉及到的服务相互关系,还需要理出受影响服务的关系,避免因为新增业务而打乱服务之间的关系。 3.3 接口设计在技术设计中,接口设计应该是自然而言的过程,很多时候api设计也并不一定是必须的;真正在实施过程中,api的定义不可避免的会出现微调。
3.4 业务流程Demo到此为止,系统的整体已经完成了,这时候应该已经能够满足业务需求了,可以根据实际中的业务流程来实验一下我们的系统了。 业务流程demo可以采用UML时序图的方式来检验,系统中每个流程跑下来,就可以看到对每个接口的调用情况和对数据库的访问情况。 4. 实施方案有了业务系统设计,剩下的就是要怎么实施了。实施中会牵涉到参与开发人员、具体的时间节点已经模块划分等,这些和每个开发团队自身情况非常相关,在这里不再多说。这里主要说说系统的上线方案和回滚方案。
专栏作者简介 ( 点击 → 加入专栏作者 ) |
|