23 | 实战一（上）：针对业务系统的开发，如何做需求分析和设计？

聊聊技术与业务 最近看了一些关于程序员价值方面的文章，很多人包括我自己有个疑问，面试时只看技术，进公司后做业务，两者矛盾么？这个问题的本质是哪个更有价值。如果你不喜欢做业务那就往中间件方向发展，做出类似高性能高可用的中间件不失为值得骄傲的事情。那么业务呢，要清楚的是公司的现金流都是来源于业务，业务产生价值。那么两者的关系是公司依赖业务，业务开发需要技术，也就是技术是更底层更通用的能力，所以自然也就更好评价，业务各不相同复杂度和场景天差地别不可复用，自然就没有比较好的评价标准。技术能力的高低决定了业务质量，而业务质量的高低反过来影响你的技术，业务复杂度上升了，之前的技术可能就不满足了，这也是技术不断更新的源动力，无法适应业务的技术是没有价值的，那么到底是什么造成了程序员价值的高低呢？我认为有以下几点： 第一，专业能力。虽然技术不断更新，但是底层的基础技术却没变，我们应该花更多时间掌握好底层技术，不变应万变。基本功扎实了才能走得更远 第二，落地能力。有了基本功后我们就具备完成一件开发任务的能力，但是怎么把事情做好却是需要不断提升的，结果导向，积极主动，有想法能落地才能体现你的价值。记住，当你开始积极主动思考一些事情后，你已经领先了大部分人 第三，终身学习能力。公司要持续发展，业务就会不断迭代发展，要让自己的技术能够匹配上业务的发展就需要不断学习，扎扎实实在自己想要专研的领域做精，你的价值也就体现出来了。 总结下：技术是业务的支撑，业务反过来影响技术，业务发展就需要提升技术。

上下层系统之间的调用倾向于通过同步接口，同层之间的调用倾向于异步消息调用，依据是什么？

课堂练习的思考，技术和业务好比生产力和生产关系的相互作用。大体上来讲，一定是相辅相成，互相作用的。当一个技术人员没有办法完成业务需求时候，那么，技术就显得更重要一些; 而当技术人员发现业务的指标都做完了，想要把业务做得更好，那么就要去深入理解业务，才能在通用技术之上构建出更贴合业务的优秀系统。 生产力，决定了整个社会价值形态的下限，而生产关系的优劣，可以影响在当前生产力局面下，社会价值形态的上限。 因此，技术可以解决温饱问题，业务可以带领走上上小康道路。

"上下层系统之间的调用倾向于通过同步接口，同层之间的调用倾向于异步消息调用。比如，营销系统和积分系统是上下层关系，它们之间就比较推荐使用同步接口调用。" 老师或者哪位大神可否就这句话展开讲讲，为什么异层同步，同层异步？

模块的划分我理解第三种也是合理的，因为积分的所有配置和规则维护应该都有积分系统完成，符合单一职责，订单、评价系统只需要发事件消息出来就可以了，他们不需要关心积分的业务逻辑，积分系统收到消息后去处理积分内部的业务逻辑。 这块不太清楚，老师怎么看？

我怎么感觉老师提的话题有点跑偏？还是好好想一想如何做好设计模式比较合理对吗？另外，老师本课带的思路也有点偏差我觉得，毕竟我们要设计的是一个积分模块而不是一个淘宝系统。架构和设计都是有演变过程的，个人认为任何撇开并发与用户数而不谈的需求是耍流氓。此处也应该循序渐进的讨论设计方而不是如此的过度设计，谢谢。

在一家国企工作，领导是个注重员工培养的人，每天都会花半个小时学习UX、产品经理相关的课程。期初都是不感兴趣的，觉得和自己无关，但今天在老师的讲课中看到一些UX相关的知识，还是非常惊喜。我觉得多学习会发现很多相关领域的知识都是可以串起来的，技术人员当然重点还是多钻研技术，但既然在公司也做业务相关的工作，为何不再花一点时间把它做得更好呢。

"上下层系统之间的调用倾向于通过同步接口，同层之间的调用倾向于异步消息调用。" 请问，这点是基于什么样的考虑，我理解应该需要同步的才用接口，其他都用异步的方式就好了吧？

为什么同层推荐消息，上下层推荐同步接口调用吗？

老师好，请教您一个问题，针对这个案例，我有一个困扰，数据库是否要维护 用户总积分这个字段，还有就是积分过期这种是如何实现方式比较好呢？ 感谢老师的回答！