客观规律:对业务系统的理解只能逐步深入
一个优秀的架构师必须明白,要设计出良好的业务系统架构,就必须先全面了解业务逻辑。
例如想要理解 Spring 的源码和设计原理,就必须首先掌握 Spring 的使用场景和方式。如果没有使用过 Spring,不了解常用的注解和 XML 配置,自然就无法理解 Spring 的源码。
一次经历让我认识到,对于业务逻辑的理解是逐渐深入的过程。 当时的营销中心,已经有了发券系统,后来运营又需要一个赠课系统。
赠课系统 + 发券系统 + 发通知系统
赠课系统简单来说就是在特定时间为一批用户赠送课程。起初我认为赠课系统和发券系统是两个独立的系统,毫无关联。然而几个月后,在新同事的点拨下,我才意识到两个系统惊人地相似,它们包含相同的部分:用户选择、指定时间和执行动作。后来我还了解到,另一个团队的通知系统也是类似的,选择一批用户,在指定时间发放通知。这三个系统唯一的不同之处在于执行的动作不同,其他部分如用户选择和定时执行都是相似的。
后来几个部门聊了一下,在给海量用户发放XX 的过程, 为了做到高可靠、高性能、高并发,大家的思路和做法都是类似的~ 原来都在忙活一件事。
基于对这三个业务的抽象,我们设计了海量用户权益触达系统。通过统一和标准化,我们消除了独立建设和重复建设系统的问题,并构建了功能更强大、性能更优越、稳定性更高的通用平台。
这段经历让我深刻认识到,如果缺乏经验,首次建设系统时很难真正理解其中的内涵。直到经过一段时间的业务迭代,有几个相似的业务出现后,才有人发现它们之间存在共性,才有人开始意识到,应该对这几个类似业务进行总结、归纳和抽象,从而构建一个更加通用的业务平台!
如果想要避免走弯路,就需要不断的学习其他人的经验,调研前辈和同行是如何建设系统的。
在没有相关经验的前提下,设计业务系统时一定会走很多弯路。想要避免踩坑就应该花时间去调研同类系统的架构设计,可以在网上多找找资料,甚至可以尝试联系文章背后的作者,也许就有热心的作者会解答你的疑问。