业务抽象能力，是研发的一项基础能力，直接关系着我们有没有时间去摸鱼、有多少时间去摸鱼的问题。业务抽象做的好，每天摸鱼无烦恼；业务抽象做的差，搬砖累死还被骂。那么，业务抽象到底是一种什么样的能力、我们应该如何去提升自己的业务抽象能力呢？

什么是业务抽象

业务抽象是将复杂的业务流程和逻辑转化为可管理和可重用的组件的过程。它的目的是简化系统的实现，聚焦于应用程序的核心功能，同时隐藏不必要的细节。抽象后设计出各种基础能力，通过对基础能力的组合和拼接，支持复杂多变的业务逻辑和业务形态。

为什么要做业务抽象

作为研发，首先我们要明白一点：只要你支持的这块业务发展的不那么差，那么你的产品经理一定会不停的向你提出需求。一旦你没有需求可以承接了，那就说明这块业务要完蛋了。随着需求的不断提出，系统功能会变得越来越臃肿，系统内部的数据流转以及本系统与外部系统的交互也会变得越来越复杂。如果没有做好业务抽象，研发很容易陷入到一片需求的大海、实现细节的泥沼中，更有甚者会引发一系列的bug或者线上事故。想想吧，你为了实现产品的某个需求，熬了三个通宵理清了系统中各种理不断剪还乱的模块关系并设计出了技术方案，然后又奋战了两个星期终于把需求上线了。你以为你完成的很完美，然而上线一段时间后却发现这个需求的改动在特定情况下会影响到另外一个系统模块的使用，最终造成了线上事故。这就是没有做好业务抽象的下场，模糊、混乱、复杂、重复开发、事故等等，会充斥着你的工作。

如何做业务抽象

既然业务抽象这么重要，那么我们怎样才能去做好业务抽象呢？一般来讲，我会遵循以下几个步骤：

1. 深入理解业务领域 在进行业务抽象之前，我首先要深入理解所涉及的业务领域。这包括与产品经理、业务分析师等相关人员密切合作，收集需求并确定关键的业务流程和实体。通过对业务上下文的深入理解，我可以在进行抽象时做出明智的决策。
2. 确定核心组件 在了解业务领域之后，我会确定系统中的核心组件或实体。这些核心组件代表系统的基本构建块。例如，在电子商务应用中，核心组件可能包括产品、用户、订单和支付等。
3. 定义接口和契约 确定了核心组件后，我会为每个组件定义清晰的接口和契约。接口定义了对组件可以执行的方法和操作，而契约则规定了期望的行为和约束条件。通过这一抽象层，不同组件之间可以无缝集成和协作。
4. 封装复杂性 业务抽象的一个重要目标是封装复杂性。通过将复杂的业务规则和流程封装在核心组件中，我确保系统的其他部分可以以简化的方式与之交互。这不仅提高了代码的可维护性，还促进了代码的可重用性。
5. 创建模块化和可扩展的架构 利用所创建的抽象，我设计了一个模块化和可扩展的后端架构。模块化的架构允许对不同组件进行独立的开发和测试，使系统更加灵活和适应未来的变化。此外，抽象层使得组件可以水平扩展，允许它们分布在多个服务器或容器上。
6. 迭代优化 业务抽象是一个迭代的过程。随着应用程序的发展和新的需求出现，我会不断优化和完善抽象。这确保系统与业务需求保持一致，并能够适应未来的增长和变化。

在这些步骤中，深入理解业务领域是最最重要的，只有你对业务领域足够了解，你才能将复杂的业务流程拆解为一个个可复用可组合的组件。

业务抽象的一个例子

如果以上的描述还是比较虚的话，那么我举个实际的案例，来说明我是如何做业务抽象的。最近陆续收到产品提的以下几个需求：

需求1：我想要在系统中加个任务发布模块，任务创建人可以在系统新建一个任务，并指定任务执行人；执行人收到飞书卡消息卡片提醒；执行人点击提醒中的按钮，打开飞书小程序，浏览任务信息；执行人可以在小程序中填写任务的执行情况；任务创建人可以在系统中看到所有执行人填写的执行情况；任务创建人点击任务完结按钮，任务关闭，执行人不能再次填写信息

需求2：我想在系统中加个信息同步模块，有权限的用户可以作为信息发布人，在系统中创建一个信息同步单；信息发布单提交后，系统默认向对应的人或者群发送飞书消息卡片，卡片内容为信息同步单中的内容

需求3：我想在系统中加个寻求帮助的模块，当业务A在处理某个case时如果遇到困难，则可以通过该模块将case信息同步到业务B，业务B收到求助的飞书消息卡片提醒，然后可以看到具体的case内容，并填写一些指导信息；B提交指导信息后，A会及时收到飞书消息卡片提醒，并可以看到B的指导内容

上面3个需求，虽然看起来各有差异，流转过程中各自依赖和需要处理的信息都不同，但是如果将其抽象并做步骤拆解的话，实际上都是在如下几件事情：

1. 创建一个任务，创建任务时可以指定对应的人或者群，也可以是默认的人或者群
2. 任务提交后，对应的人或者群会收到消息提醒
3. 任务接收人收到提醒后，可以查看任务信息
4. 任务可以有打开和关闭两种状态，任务打开的情况下接收人可以填写反馈信息，任务关闭的情况下则不允许接收人填写反馈信息
5. 接收人填写反馈时可以消息提醒创建人
6. 任务流转过程中，后端系统实际不必感知任务的具体内容是什么【当做一个大json就好】，后端系统只需要知道任务类型【每个需求对应一个任务类型】，并基于一定的优先级确定任务接收人【优先取任务创建时的人/群，取不到则取任务类型对应的默认人/群】，然后基于任务类型查找对应的飞书消息卡片模版【同一个任务类型在创建和反馈提交时可以配置不同的消息卡片模版】，在基于消息卡片模板里面配置的字段Key从任务内容【大Json】里面取对应的值来构建消息卡片，然后做卡片推送；任务提供接口来支持任务状态的变更，从而控制是否可以继续追加反馈信息

通过以上的业务抽象，我们将后端的工作大大简化，后端只需要向前端提供几个公共接口，就可以使用同一套基础能力支持3种业务需求。后续有类似的功能需要开发时，后端只用新增几个配置项就即可。就是这么丝滑顺畅，又有时间来好好摸鱼了。

总结

作为一个后端研发，业务抽象是我们创建可扩展和易维护系统的重要技能。通过深入理解业务领域、确定核心组件、定义接口和契约、封装复杂性以及创建模块化架构，我们就能够有效地抽象业务逻辑并构建健壮的后端解。

未来可期，摸鱼万岁，加油💪🏻