守株阁

金额、日期和申请编号为什么不能只看 Java 类型 采购申请的明细写着单价 19.90、数量 3，汇总金额应由服务端计算为 59.70。对象里使用 BigDecimal，不等于数据库已经保存了正确金额：乘法输入可能有三位小数，列可能只留两位，重新读取后也可能出现表示形式的变化。类似地，审批时间写进 Instant 并不能自动回答数据库列用什么时区解释；@Id 放在字段上也没有替业务决定重试时如何识别同一张申请。把这三类问题放在一起，是因为它们都发生在 Java 值跨过持久化边界的地方，却由不同层负责。 本篇源码、迁移、脚本与测试可从固定版本完整归档取得；版本 1b08ada，SHA-256 见源码清单。 这里沿用采购域的约束：DRAFT → SUBMITTED → APPROVED → ORDERED，或者 SUBMITTED → REJECTED；只有 APPROVED 能建订单，每张申请至多一单，租户不能越权。本文集中在明细单价、申请金额、下单时间和身份的表示，不把业务校验、数据库约束和 JPA 映射混成一个注解。先修实体生命周期和持久化上下文（系列 01）；涉及提交后重读时...

同一个 Servlet 为什么不能保存本次申请 ID 采购员访问申请查询入口，带来申请 ID、租户信息和可能重复的查询参数。看起来只需在 Servlet 中解析 ID、调查询服务、输出结果。如果把 requestId 临时写入 Servlet 实例字段，另一个请求可能在第一个请求尚未输出时覆盖它；若先把响应发给客户端，再检查租户归属，即使发现越权也收不回已经发送的字节。Web 入口的第一条契约不是某个注解，而是每个请求有自己的输入、输出与终止时点。容器可复用一个 Servlet 实例，不能把这个实例当作每次请求独占的工作区。 本篇源码、迁移、脚本与测试可从固定版本完整归档取得；版本 20261005-local（基于 1b08ada），SHA-256 见源码清单。 本系列仍在隔离的 Open Liberty 26.0.0.5、Jakarta EE 11 Platform、Java 21、PostgreSQL 16.15 上讨论采购审批；本章只核对 HTTP/Servlet 边界，不拿一次回声响应证明采购查询、鉴权和数据库读写。工程已有 RequestEchoServlet.jav...

Maven 能编译，为什么部署时仍可能缺类 采购系统已经分出领域、用例、JDBC 适配器和 Web 四个 Maven 模块。构建机器上这几个项目彼此可见，部署机器却只拿到一个 WAR：服务器不会到开发者工作目录寻找 domain/target/classes。另一种失误刚好相反：以为 Jakarta EE API 用得多，就把 API JAR 连同应用类打包进 WEB-INF/lib，让应用带着和服务器提供的 API 同名的类。两种问题都要从包的内容和规范规定的可见性排查，不能只看 pom.xml 里写了依赖。 本篇源码、迁移、脚本与测试可从固定版本完整归档取得；版本 20261005-local（基于 1b08ada），SHA-256 见源码清单。 本章仍采用单 WAR。前两章的采购约束没有变：明细价格由服务端确定，非法审批状态拒绝，一张申请至多一张订单。检查 WAR 的目的只是确认运行这些代码所需的类位于正确位置，不表示这些业务路径已经通过 HTTP 或数据库验收。实际 RestApplication.java 把 REST 根设为 /api；HealthResource.j...

同一个申请，为什么不让 HTTP 资源直接写 SQL 采购员提交一张申请，审批员决定是否通过，订单员才可以下单。第 01 章把路径限定为 DRAFT → SUBMITTED → APPROVED → ORDERED，或由 SUBMITTED → REJECTED；总额由服务端计算，同一申请最多一张订单。一个 Servlet 如果同时读取 HTTP 参数、判断审批状态、拼接 SQL，就把业务规则和传输协议绑在一起。将来从 REST 换成批处理，即使仍是同一次审批，也得重写判断；不启动服务器就很难验证非法状态是否被拒绝。单体不妨先划清边界，再决定是否增加运行进程。 本篇源码、迁移、脚本与测试可从固定版本完整归档取得；版本 20261005-local（基于 1b08ada），SHA-256 见源码清单。 这里的“模块”有三层含义：Maven 构建模块决定编译依赖，Java 包与接口决定源码能看见哪些类型，WAR/EAR 是部署单元。这三层不自动对齐。把 domain 单独编成 JAR，不能阻止应用反射访问它；把服务放进不同 Maven 子工程，也不会凭空产生不同的运行时进程。第 03...

一份合同实收 1000 分，客户申请退款 300 分。请求可能重复，退款提交后进程可能退出，结算方收到通知并入账后也可能来不及确认。架构评审需要回答这些具体窗口会留下什么数据，而不是检查设计图中是否出现足够多的模式名称。 本篇将“租户范围内的部分退款”作为独立变化，使用两个 SQLite 文件分别表示租赁与结算持久状态。实验验证单库事务、并发重复请求、持久待发记录及接收方去重；本地函数调用承担传递工作，没有消息中间件、公网、真实支付或新页面。对应能力保留 NOT_RUN，综合章节的发布不改变前章证据边界。 业务契约先于模式选择 退款金额必须为正，累计退款不能超过实收；同一个租户内，同一个退款键重复提交相同金额应返回已有结果，改成不同金额必须拒绝；不同租户可以使用相同合同编号。合法退款在租赁库提交后，最终应在结算库形成同额入账，重复投递不能增加结算金额。 样例以 A、B 两个租户，各自拥有合同 1，实收均为 1000 分。主体 alice 只属于 A，bob 只属于 B。此映射沿用教学边界，不代替真实认证。所有金额固定 CNY 整数分，不涉及部分履约、支付通道费用、税务冲销或跨币...

旧租赁系统用 cents 保存合同金额，新实现准备采用 amount_minor 与 currency。替换一个字段看似简单，实际存在多个同时运行的事实：旧版本还在写，历史行尚未回填，新版本可能只接管部分租户，而回退按钮只能切换代码，无法撤销已经提交的数据。 本篇用 SQLite 文件数据库演练一个受限迁移：保留旧字段，增加兼容字段，通过稳定写入入口按租户路由；回填中途退出，再从检查点恢复；最后切回旧实现并继续写入。实验中的副作用是数据库 effects 记录，没有访问外部支付或通知服务，线上网关、跨机器复制和真实流量迁移均为 NOT_RUN。 先确定回退以后谁读什么 迁移的第一份契约应描述旧版本仍然需要的列、类型和含义。旧读取 cents，固定解释为 CNY；新读取优先使用 amount_minor 和 currency，尚未回填时退回旧字段及 CNY。两条读取路径对同一合同必须返回相同金额与币种，比较应在实际数据上执行，不能只比较两份接口定义。 因此，这次变化只允许 CNY。若新版本开始写 USD，旧版本把同一个数字解释为人民币，即使 SQL 能执行，业务也已经不兼容。新增...

设备租赁的客户差异有时只是一项费率，有时改变整个计费算法。把所有差异塞进配置，配置会逐渐拥有条件与循环；把每个字段都做成插件，简单产品又需要维护加载器、版本协议和异常边界。扩展点应由实际变化决定，并且留下普通条件分支可以解决问题的对照。 本篇保留日计费和整周优惠两种策略，再增加一个受限封顶插件。实验使用 Python 3.14 的标准库从批准的本地文件加载插件，不使用 Java ServiceLoader，也不把进程内插件说成安全沙箱。相同八天、一百分日费率，三种行为分别产生 800、700、500 分，差异来自明确规则，不来自名称不同的空实现。 参数、策略与插件分别改变什么 日计费按天数乘单价。整周优惠将每七天计为六天，剩余天数照常计费；八天对应七个计费日，因此是 700 分。封顶规则取普通日租总额与 500 分的较小值，八天得到 500 分。金额统一使用整数分，输入只描述受限报价，不包含税率、押金、跨币种转换和合同变更历史。 若客户差异只是每日单价，保留同一函数并传不同参数足够。整周优惠改变运算规则，适合独立策略函数。封顶规则由另一个批准模块提供，需要加载时验证能力与接口版...

两家租赁公司都可能有编号为 1 的合同。公司甲的金额为 100，公司乙的金额为 200，合同编号相同并不表示同一业务对象。多租户系统需要把公司身份一直保留到查询、缓存、任务与幂等记录，任何一层只留下合同编号，都可能把另一家公司的结果交给当前请求。 本篇采用合成数据演示一个受限方案：H2 2.1.214 中每个租户一个 schema，每个 schema 配一个应用账号。管理员负责建表和授权，业务查询使用 APP_A、APP_B。实验验证数据库权限与应用上下文的组合，消息部分只运行消费函数和持久 Inbox，没有启动消息中间件；线上身份认证、密钥轮换和跨机器攻击测试均为 NOT_RUN。 租户身份从哪里来 租户标识可以出现在请求头、路径、消息和配置项中，但这些位置提供的是请求声明。服务必须先依据已认证主体的授权关系确定可访问公司，再比较声明。代码以固定映射 alice→A、bob→B 代替真实身份系统，输入为空或 alice 声明 B 都在建立数据库连接前失败。这个映射证明检查顺序，不能证明真实令牌不可伪造。 一种常见错误是把请求头直接转成连接池键。攻击者修改标识后，应用会用自己的...

租赁申请需要店员审核，审核期间服务可能重启。后来流程增加主管复核，已经提交的旧申请是否也要补一道审核，不能只靠替换一个流程文件回答。等待中的实例、任务归属和流程版本都必须有持久记录。 本篇将两份 BPMN 模型部署到真实 Camunda 7.23 引擎，以 H2 文件数据库保存等待状态。第一次创建人任务后直接终止 JVM，再用新进程恢复，随后部署第二版，比较新旧实例的路径及普通代码的同一转换规则。 引擎承担等待和继续的执行 普通业务代码可以计算下一步是审核还是结束，但跨越数小时的人工等待还涉及任务持久化、恢复、查询和历史记录。工作流引擎把这些执行机制集中起来，领域规则仍需由应用明确提供。流程节点存在，不表示审批权限或租赁条件已经正确。 BPMN 是流程模型与表示规范；具体引擎只执行自己支持的元素和扩展。本实验使用开始事件、顺序流、人任务和结束事件，没有覆盖整个 BPMN 标准，也没有把能够解析 XML 等同于全部语义通过。OMG BPMN 2.0.2 Camunda 的 User Task 在流程到达时创建等待处理的任务，应用可以查询并完成任务。样本直接调用引擎 API 完成它...

设备预留已经提交，扣费却被拒绝，合同需要释放预留。释放也可能失败，甚至已经释放成功但协调器还没记录结果就退出。把这段逻辑写成一个 try-catch，只能处理仍在运行的调用栈，无法回答新进程该从哪一步继续。 本篇用三个独立 H2 数据库分别保存协调状态、库存操作和收费结果，主动在参与者提交后终止 JVM。恢复进程根据持久记录继续补偿，检查重复释放、迟到成功事件以及交付以后不能自动撤销的边界。 补偿是另一次业务操作 Saga 将长事务分成可分别提交的事务，并为需要撤销的步骤安排补偿。前面已经提交的结果不会因为后续某个进程抛异常而自动回滚，补偿也可能需要新的尝试。原始Sagas论文；Saga模式 设备预留的补偿可以是释放预留，但这并不等于时间倒流。预留期间其他合同可能已被拒绝，业务系统也可能产生审计或通知。实验只检验资源持有状态与释放次数，不声称所有外部观察都恢复到预留前。 协调器保存 R1、R2 的当前状态和每次迁移原因。库存数据库保存资源 held、releases 及操作编号；收费数据库保存操作编号和整数金额。三者通过各自 JDBC 连接提交，不共享一个能够整体回滚的数据库事...