Repository

一个修改商品价格的功能，接口检查价格是不是整数，应用服务检查一次，领域对象检查一次，保存时又检查一次。代码分成了四层，同一个问题也被问了四遍。 这些检查看起来都在提高可靠性，但如果删掉其中一条，我们能说清楚究竟失去了什么保护吗？ 之前的《让领域模型和仓储模型各自负责》讨论了模型与持久化之间的边界。这篇继续讨论一个更具体的问题：边界已经划分之后，哪些检查应该保留，哪些可以交给前面的代码保证？ 如果你已经接触过 Python 的 dataclass 和简单分层，但觉得业务代码越来越像校验框架，可以从下面这个改价功能开始。 一个价格，为什么检查四遍 假设商品后台收到这样的 JSON： { "sku": "P1001", "price_cents": 9900 } 价格使用整数分。对于这个例子，业务还约定：价格不能为负数，停售商品不能改价。 容易写出的代码是，在入口、服务、模型和 Repository 中都放上类似判断： if type(price_cents) is not int: raise ValueError("价格必须是整数分") 问题在于，这四次检查通常处理的是同一个已经解析完成的值。只要内部代码没有重新引入不可信数据，重复检查提供的保护就很有限。 真正需要区分的是两个问题： 问题 例子 负责的位置 输入是否符合接口约定？ 缺少价格、价格是字符串 外部输入入口 操作是否符合业务规则？ 负价格、对停售商品改价 领域模型 应用服务负责组织操作：加载商品、调用改价方法、保存商品。Repository 负责读写和映射。它们不需要把前两类判断各自重写一份。 先建立一个可以信任的入口 Python 的类型注解不会自动验证运行时数据。写下 price_cents: int，并不能阻止调用方传入字符串。 因此，“内部可以信任类型”需要前提：外部数据进入内部流程之前，确实经过了解析和检查。 下面是这个入口。示例采用严格协议，只接受两个字段；不自动把字符串价格转换成整数。 from dataclasses import dataclass, replace @dataclass(frozen=True) class ChangePriceRequest: sku: str price_cents: int def decode_change_price(data: object) -> ChangePriceRequest: if not isinstance(data, dict): raise ValueError("请求必须是 JSON 对象") if set(data) != {"sku", "price_cents"}: raise ValueError("请求必须且只能包含 sku 和 price_cents") sku = data["sku"] if not isinstance(sku, str) or not sku.strip(): raise ValueError("sku 必须是非空字符串") if type(data["price_cents"]) is not int: raise ValueError("价格必须是整数分") return ChangePriceRequest(sku.strip(), data["price_cents"]) 这里使用 type(value) is int，是因为 Python 的 bool 是 int 的子类。这个接口不接受 true 作为价格。 ...

一个策略选择工具，本来只需要让 Agent 查看模板、选择版本、取得写作规则。写着写着，代码却变成了另一副样子：遍历字段名、判断字典形状、检查数组元素、猜测字段类型，再把已经检查过的数据交给下一层继续检查。 每一条判断单独看都有解释，放在一起却让人看不清工具到底做什么。 这发生在一次写作策略工具教程的审查中。删除一个通用转换助手后，代码甚至更长了：检查没有减少，只是搬进了另一个函数。问题并不是少用了一个框架，也不是变量命名不够规范，而是还没决定哪些错误需要处理，就先把能想到的检查写了出来。 本文适合已经了解 Python dataclass、正在让 Agent 编写小型工具或分层应用的读者。以下例子从那次审查中缩小而来，用来说明设计取舍，不是完整策略工具的实现。 前两篇分别讨论模型与仓储的职责和入口检查与业务约束的分工。这篇往前追问一步：在决定校验放在哪里之前，我们为什么需要这条校验？ 一个数组转换，怎么长成了通用校验器 假设模板包含 structure 字段。JSON 中它是数组，领域对象中希望用 tuple 表示： structure = tuple(data["structure"]) 这行代码完成转换，但不保证输入正确： assert tuple("post") == ("p", "o", "s", "t") 如果 Agent 把数组写成字符串，转换不会报错，错误会以另一种形式进入模型。因此，在接收 Agent 请求的地方，检查它是不是字符串数组是有具体理由的。 但这不意味着每个处理 structure 的方法，都应该重新执行下面三项检查： 它是不是数组？ 数组里的元素是不是字符串？ 数组是不是非空？ 前两项属于输入协议；第三项取决于业务：这个模板是否允许没有正文结构？如果模型已经保证结构不能为空，入口无需重复保证一次。 同样的字段，也可能来自程序自己写出的文件。是否检查，要先确定文件的使用方式。 数据来源 能依赖的前提 处理方式 Agent 提交的编辑 JSON 尚未确认类型和字段 入口解析，拒绝不符合约定的结构 已解析的内部请求对象 调用者遵守既定契约 直接使用，不重复判断类型 同一程序写出、没有独立编辑入口的文件 写入与读取遵循同一格式 可以直接映射，加载失败时暴露错误 允许人工编辑或导入的文件 内容可能不符合格式 把文件读取当作输入边界，定义需要的检查 “放在仓库里”不等于“可信”。如果维护者经常手改 JSON，它就是一个真实的编辑入口。反过来，受控文件也不是永远不会损坏；选择直接映射，意味着不承诺为每一种损坏提供定制诊断，更不保证发现所有能被转换的错误类型。 一个能直接运行的例子 缩小需求：模板名称不能为空，结构至少有一项，每一项不能是空白文字。外部请求只接受 name 和 structure，不自动转换数字或字符串数组。 保存下面代码为 template_boundary.py，使用 Python 3.10 或更新版本运行： from dataclasses import dataclass @dataclass(frozen=True) class Template: name: str structure: tuple[str, ...] def __post_init__(self): if not self.name.strip(): raise ValueError("模板名称不能为空") if not self.structure or any(not step.strip() for step in self.structure): raise ValueError("模板必须包含非空的写作步骤") def decode_template(data: object) -> Template: if not isinstance(data, dict) or set(data) != {"name", "structure"}: raise ValueError("请求必须包含且只能包含 name 和 structure") if not isinstance(data["name"], str): raise ValueError("name 必须是字符串") steps = data["structure"] if not isinstance(steps, list) or not all(isinstance(step, str) for step in steps): raise ValueError("structure 必须是字符串数组") return Template(name=data["name"], structure=tuple(steps)) def writing_outline(template: Template) -> str: return "\n".join(f"{i}. {step}" for i, step in enumerate(template.structure, 1)) if __name__ == "__main__": template = decode_template({ "name": "问题与解释", "structure": ["提出具体问题", "解释原因与适用条件"], }) print(writing_outline(template)) cases = [ ({"name": "问题与解释", "structure": "post"}, "structure 必须是字符串数组"), ({"name": "问题与解释", "structure": [42]}, "structure 必须是字符串数组"), ({"name": "问题与解释", "structure": []}, "模板必须包含非空的写作步骤"), ({"name": "问题与解释", "structure": [" "]}, "模板必须包含非空的写作步骤"), ({"name": " ", "structure": ["解释"]}, "模板名称不能为空"), ] for payload, expected in cases: try: decode_template(payload) except ValueError as error: assert str(error) == expected else: raise AssertionError(f"错误输入被接受：{payload!r}") print("正常输入和 5 个失败场景均符合约定") 运行 python3 template_boundary.py，输出： ...

在业务系统逐渐变复杂时，一个对象往往同时被拿来承载业务规则、数据库字段和 HTTP 响应。开始时这很省事，后来却会出现连锁问题：数据库新增一个内部字段，接口结构跟着变化；领域代码为了查询数据而依赖 ORM；仓储把 SQLAlchemy 行对象直接交给控制器。 更稳定的做法，是让不同边界拥有不同模型，并通过转换连接它们： Controller -> Domain Model -> Repository Contract -> ORM Model -> Database | ^ +------ API Request/Response ---+ 这里的重点不是增加更多目录，而是明确每个模型对谁负责。也不需要为每个领域类都复制一套存储类：仓储结果可以直接组合领域对象与读取元数据，只有确实不同的格式或契约才需要独立表示。 四类模型，各自回答一个问题 领域模型回答“什么状态符合业务规则”。例如商品必须有 SKU 和名称，价格不能为负数。SKU 是业务标识，数据库自增 id 则不必进入领域对象。领域模型不应该导入 SQLAlchemy、Pydantic 或 Web 框架。 ORM 模型回答“如何把数据存进数据库”。它可以拥有自增主键、外键、索引、时间戳和数据库约束，但这些细节不必进入领域对象。 Repository 契约回答“应用可以怎样保存和读取数据”。它的参数和返回值属于仓储边界：保存商品可以返回 StoredProduct，其中包含领域对象和 updated_at；分页查询可以返回 ProductPage 这样的查询模型。 API 模型回答“客户端能发送和接收什么”。请求模型负责输入形状，响应模型负责 HTTP 输出。例如商品响应可以包含 updated_at，并将其序列化为日期字符串；这不意味着商品领域对象也需要这个字段。 一个最小例子 假设一个后台允许按 SKU 保存商品，再查询商品信息。下面使用同步 SQLAlchemy 2.x 展示关键代码，省略数据库连接和 HTTP 路由配置。 领域对象放在 app/domain/product.py，只表达业务状态。价格统一使用人民币分，避免浮点数表示金额： from dataclasses import dataclass @dataclass(frozen=True) class Product: sku: str name: str price_cents: int def __post_init__(self): if not self.sku or not self.name: raise ValueError("商品 SKU 和名称不能为空") if self.price_cents < 0: raise ValueError("商品价格不能为负数") 数据库模型放在 infra/db/models.py。自增主键、唯一约束和更新时间属于存储设计： ...