我建议用如下的一个过程：
参考最佳实践 → 结合实际情况权衡 → 选择当前最合适的方案。
第一阶段：先不要急着创新，先学习最佳实践
不要太早相信自己的判断，一般来说是有如下经历的程序员才敢这么做的：
- 参与过多个真实系统；
- 经历过很多个线上事故；
- 参与开发过很多个复杂模块或者系统。
没有足够经验之前，所谓的自己的设计，很多时候都不太靠谱。
所以第一步，不是创新，而是学习。
看看优秀项目怎么做，看看行业里面经过验证的方案是什么。
这个阶段不要觉得参考别人就是没有思想，恰恰相反。
大量吸收优秀设计，是建立自己技术判断力的过程。
你也可以认为这是一个建立审美的过程，你需要先知道什么是好的设计。
但是，最佳实践不一定就是最佳方案
你不能看到别人用了，就照抄，所谓最佳实践，都是有前提条件的。脱离实际的业务场景谈最佳实践，没有意义。
真正的问题不是别人怎么做，而是在我的当前场景下，什么方案最合适？
举一个实际例子。
假设现在有一个需求，用户下单成功后，需要通知下游系统：订单已经创建完成。
这个问题怎么解决？如果你去搜索资料。
很多文章都会告诉你使用消息队列MQ。
为什么？
因为MQ确实是一个优秀方案，订单服务发送一条OrderCreated事件。然后库存系统订阅，积分系统订阅，物流系统订阅。
以后新增一个支付系统、营销系统，也只需要订阅这个事件。
订单服务完全不需要修改。单单从架构设计角度来说，这是非常优秀的解耦方式。
但是问题来了。你的系统是什么情况？
如果你的系统目前只是一个简单单体应用，订单只是其中一个模块而已，且未来半年也没有拆分计划。
这个时候引入MQ，真的好吗？
你需要考虑：
- 增加消息中间件的运维成本；
- 增加消息可靠性问题；
- 增加重复消费问题；
- 增加异常处理复杂度；
- 新增MQ实例带来的费用(有成本问题)。
为了一个简单通知，引入整个MQ体系，可能反而增加了系统复杂度。
那么这个时候，更合适的方案可能是什么？用Spring自带的事件监听机制就可以了。
订单创建完成后，发布一个OrderCreatedEvent。然后其他Service监听这个事件。
订单服务不知道谁消费，其他模块只需要订阅事件即可，它同样实现了一定程度的解耦。
但是成本远低于MQ，所以对于当前这个单体应用来说，Spring Event才是真正合适的方案。
这就是架构设计里面很重要的一点：
不要寻找最先进的方案，要寻找当前最合适的方案。
但是问题又来了：如果自己没有判断能力怎么办？
这其实是很多程序员成长过程中都会遇到的问题。
你知道需要权衡,但是你没有权衡经验。
怎么办？
答案是：问团队里的高手。
但是注意，不是让别人直接替你做决定。
而是像前面提到的那样，先自己研究，有了自己认为最好的方案，这个时候再去请教团队里的高手，效果好很多的。
因为这时候你不是问这个问题怎么解决，而是带了自己的方案过去了问的。
那如果连高手都没有怎么办？
那还能怎么办，只能自己承担这个选择，软件工程本来就是不断试错和迭代的过程。
你可以先按照自己的思路写代码，然后正常上线。只是说，上线后，要持续观察，且有新需求到来后，看看之前的设计是否还能支持。
如果不行，那就优化代码设计，就可以了。
小结
软件工程从来不是追求最复杂、最先进的技术，而是在当前约束条件下，找到最合适的解决方案。
这才是工程师真正的创造力。