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