【架构入门系列】从业务到平台的思维转变

一个需求：抽奖系统

如果你接到了一个开发需求：开发一个抽奖活动的后台系统。第一反应如果是打开IDEA，新建一个项目，输入项目名：lottery。然后开始根据需求着手开始进行设计数据库，api，然后进行开发，你并没有错，这是太平常不过的开发流程。

过了一段时间，你又接到一个类似的需求：开发另一个抽奖活动的后台系统，但是里面的一些业务逻辑、流程处理不太一样，然后就把前一个完成的后台系统copy过来，准备开始修改。

是时候停止这种低效且愚蠢的开发方式了！本文将告诉你如何将你的思想转变过来，用偏后端的思维、尽量易懂的图文、尽量精简的代码、尽量多的例子来将你的等级从熟练的业务驯服者提升为初阶架构猎人。

反思：做错了什么

使用复制、粘贴、修改的方法去开发一个类似的新的业务系统，从开发效率上来说挺高的，但仍然存在以下问题：

• 代码复用性低。类似的业务系统可能越来越多，复制粘贴导致代码的重复率太高，可复用性太低
• 测试、部署效率太低。需要当做一个新的后台服务新建一套测试、构建、部署、发布流程并进行实施，对一些通用的业务逻辑进行了重复的测试，构建发布流程也需要单独管理
• 收集数据难度大。类似的业务系统的数据被分散在不同的数据库、日志中，如果想收集汇总分析一些通用的业务日志难度大
• 业务系统太过私有化，无法提供类似SAAS服务那样让任何人都能创建自己的抽奖活动

老鼠的视力很差，它没有办法看到远处的事物，但是我们为了日后业务系统的重复利用，就需要尽量避免鼠目寸光的二次开发。

所以，需要将业务系统抽象为业务平台，支持通用的业务流程，让业务平台为日后的类似