业务逻辑封装的核心是按职责边界切分并暴露稳定接口：从真实业务动作识别闭环单元（如“校验库存”），明确单一责任，隔离实现细节，定义清晰契约，并融入展示层、应用层、领域层、基础设施层的分层架构。

把业务逻辑用封装思想拆分，核心是“按职责边界切分，对外只暴露必要接口”。不是简单地把代码塞进函数或类，而是围绕“谁在什么场景下需要什么能力”来组织代码结构。

识别可独立存在的业务单元

先从真实业务动作出发，找出具备完整输入、处理、输出闭环的最小颗粒度。比如电商下单流程中，“校验库存”“计算优惠”“生成订单号”“扣减库存”都不是孤立步骤，但“校验库存”可以独立成一个单元：它只依赖商品ID和数量，返回是否可售，不关心用户身份、支付方式或物流策略。

• 每个单元应有明确责任，例如“只做风控判断”或“只负责发短信通知”
• 避免一个模块既查数据库又写日志还调第三方API——这些应拆到不同层
• 参考现实角色：就像财务部不管仓库发货，但能拿到发货结果做账

定义清晰、稳定的外部契约

封装后，其他模块只能通过你提供的接口与之交互。这个接口要像合同一样稳定：输入格式固定、输出含义明确、异常情况可预期。

• 用函数参数或对象字段声明必需信息，如checkStock({ skuId: 'A001', quantity: 2 })
• 返回值统一结构，例如{ ok: true, data: { available: true } } 或 { ok: false, error: 'OUT_OF_STOCK' }
• 不暴露内部状态变量（如不提供getCacheHitRate()），除非这是该模块的核心能力

隔离实现细节，允许内部自由演进

只要接口不变，内部怎么实现都可以换。今天用内存缓存查库存，明天换成Redis或远程服务，调用方完全无感。

• 把数据库查询、HTTP请求、配置读取等具体技术实现藏在模块内部
• 避免在接口里暴露技术名词，例如不用getOrderFromMysqlById()，而用getOrder(id)
• 测试时可轻松替换为模拟实现（mock），比如用假数据代替真实风控服务

配合分层结构落地封装

单靠一个类或函数不够，需嵌入整体架构中。常见四层划分：

• 展示层：只管渲染和事件转发，不处理业务规则
• 应用层：编排多个业务单元，比如“下单”调用库存校验+优惠计算+订单生成
• 领域层：存放核心业务逻辑单元，如StockChecker、CouponApplier
• 基础设施层：封装数据访问、消息发送、文件存储等技术细节