应使用规格模式封装业务规则，而非硬编码SQL；DAO只负责数据映射与原子操作，事务由service层控制，数据库约束仅作兜底，不可替代业务规则验证。
用规格模式封装业务规则，而不是写在 SQL 或 DAO 里
直接在 executeQuery 前拼 SQL 判断“年龄 > 18 && isPremiumMember == true”，等于把规则硬编码进数据访问层。一旦规则变（比如加个“注册满30天”），你得改 DAO、测 SQL 注入、连带改测试用例——这不是分离，是绞杀。
正确做法是让业务规则自成体系：定义 ISpecification 接口，每个具体规则（AgeGreaterThanSpec、PremiumMemberSpec）只管自己那一条逻辑；组合时用 And()、Or() 拼装，不碰数据库连接、不依赖表结构。
- 规则类只接收
const User&，不接触mysql_real_connect或sqlite3_exec - DAO 层只负责“查出原始数据 → 构造
User对象 → 交给规格判断”，不参与条件计算 - 测试时可直接 new 一个
User调用spec.IsSatisfiedBy(user)，无需启数据库
DAO 返回领域对象，不是 raw result set 或 vector<string>
常见错误是 DAO 的 queryUsers() 返回 std::vector<:vector>></:vector>，然后在 service 层手动 for 循环赋值给 User。这导致业务逻辑被迫感知字段顺序、空值处理、类型转换——规则和数据耦合死死的。
DAO 应该返回明确的领域类型，比如 std::vector<user></user> 或 std::optional<user></user>。构造过程封装在 DAO 内部：用 mysql_fetch_row 取出数据后，立即调用 User{row[0], std::stoi(row[1]), row[2] == "1"} 这样的构造函数或工厂函数。
立即学习“C++免费学习笔记（深入）”；
- 避免在 service 层出现
if (row[3] != nullptr) user.status = parseStatus(row[3]) - 如果数据库字段名变更（如
is_premium→is_subscribed），只改 DAO 的构造逻辑，不影响规格类 - 配合 C++17 的结构化绑定，service 层可直接写
for (const auto& [name, age, isPremium] : users)
事务边界由 service 控制，DAO 不 commit/rollback
DAO 里写 mysql_query(conn, "START TRANSACTION") 是典型越界。事务不是数据访问细节，而是业务一致性契约——比如“扣款 + 发通知 + 更新积分”必须原子执行。这个语义只能由 service 层理解并决定。
DAO 只暴露带 mysql_conn_t* 参数的原子操作：insertUser(mysql_conn_t*, const User&)、updateBalance(mysql_conn_t*, int userId, double delta)。service 层用 RAII 封装事务（例如 TransactionGuard 类，在析构时自动 commit 或 rollback），把多个 DAO 调用包进去。
- DAO 函数内部不调用
mysql_commit，也不检查mysql_errno后自行重试 - service 层拿到 DAO 返回的
bool或std::expected，再根据业务规则决定是否回滚（比如规格不满足就直接 rollback，不执行后续操作） - 这样，规格判断可以放在事务开始前（快速过滤）、也可以放在事务中（需回滚的强校验）
别让数据库约束替代业务规则验证
加个 CHECK (age >= 0) 看起来很安全，但实际掩盖了问题：这个约束无法表达“VIP 用户年龄可为 -1（表示未填写）”，也无法触发友好的错误提示（比如“请先完成实名认证”）。数据库约束是兜底，不是第一道防线。
规格模式应在 service 层前置运行：用户提交表单后，先走 CompleteProfileSpec.And(ValidAgeSpec).IsSatisfiedBy(input)，通过才进 DAO。失败时直接返回结构化错误码和提示文本，不浪费一次数据库 round-trip。
- 数据库唯一索引（如
UNIQUE(email)）仍要保留，但它只解决并发冲突，不替代EmailFormatSpec这类格式校验 - 外键约束（
FOREIGN KEY (dept_id) REFERENCES dept(id)）是数据完整性保障，但“禁止删除被引用的部门”属于业务规则，应由DepartmentInUseSpec在 service 层拦截 - 过度依赖数据库约束会让单元测试变重——你得 mock 整个 MySQL 实例，而不是只 mock 一个
ISpecification
true 或 false——这个布尔值背后，才是你花时间梳理清楚的业务边界。 
