业务逻辑才是真正的产品（于是我构建了logicrepo）

Source: Dev.to

如果你曾经因为一个没人能解释的业务规则而发布了带 bug 的代码，这篇文章适合你。

一个定价规则在生产环境中失效。
客户受到影响。
大家都在手忙脚乱。

随后出现了最糟糕的问题：

谁改了它… 为什么？

有时逻辑埋在服务层里。
有时它被拆分到校验器和特性开关中。
有时它写在没人再信任的 Confluence 文档里。

这不是工具的问题。
而是结构的问题。

业务逻辑没有一等公民的归宿

在大多数代码库中，业务逻辑：

• 与框架和基础设施代码混在一起
• 难以单独审查
• 测试不足（或间接测试）
• 单独记录——如果有记录的话

在审查 PR 时，你常常能看到实现方式，却看不到到底是哪条规则被修改了。这很危险，因为业务逻辑才是真正的产品。

为什么在 AI 时代这点更重要

AI 可以生成控制器、服务和校验器。
但它生成不了领域意图。

业务逻辑编码了：

• 定价决策
• 资格标准
• 风险约束
• 产品策略

随着代码生成成本下降，意图的清晰度变得更有价值——而不是更不重要。

思路：将意图与实现分离

我希望业务规则具备：

• 明确性
• 版本化
• 可测试性
• 可审查性
• 与框架无关

于是诞生了 logicrepo。

什么是 logicrepo？

logicrepo 是一个简单的 CLI，帮助你：

• 用 YAML 定义业务规则
• 为这些规则编写测试
• 在 CI 中进行校验

没有运行时魔法。没有框架锁定。只有规则，表达清晰。

示例（简化版）

rules:
  discount:
    when:
      user.plan: "pro"
    then:
      apply_discount: 20

测试关注意图，而不是实现细节。

为什么选 YAML？

并不是因为它流行。YAML 的优势在于：

• 人类可读
• 在 PR 中易于 diff
• 非工程师也能审查

当规则变更时，产品经理和领域专家真的能看懂改了什么——而不仅仅是“有东西改了”。

CI 作为护栏

运行它故意要显得枯燥：

npx logicrepo check

本地运行，也在 CI 中运行。如果业务规则出错：

• 构建会失败
• 变更会被显现
• 意图会被记录

不再有悄无声息的逻辑漂移。

这不是规则引擎

logicrepo 不在运行时执行你的业务逻辑。可以把它当作：

• 真相来源
• 合约
• 业务规则的规范

你的应用可以消费它，或者仅仅用它来自我校验。

试一试

npx logicrepo check

期待听到你的想法：

• 你的业务逻辑现在在哪里？
• 你是否曾因逻辑漂移而吃过亏？
• 这样的工具能帮助你的团队吗？