复杂业务逻辑该不该塞进 MySQL 存储过程？
不该。MySQL 的存储过程不是业务逻辑容器，而是数据操作的辅助工具。一旦把订单状态流转、库存扣减规则、积分计算策略这类带分支判断和外部依赖的逻辑硬塞进
PROCEDURE或
FUNCTION，就会立刻遇到三类硬伤：调试困难（无断点、日志弱）、测试脱节（无法单元测试）、部署耦合（DB 变更需 DBA 审批且难灰度）。真实项目中，95% 的“存储过程越写越长”都源于过早放弃领域建模，转而用 SQL 拼凑状态机。
用 OOP 建模时，哪些数据库字段必须对应为对象属性？
只映射**有业务语义的、可被约束或参与计算的字段**。比如订单表中的
status字段，不能直接暴露为 public 属性，而应封装成
OrderStatus枚举类，并在
cancel()、
ship()等方法里校验状态迁移合法性；
total_amount也不能是裸 float，要绑定货币类型和精度控制。反例：把
created_at、
updated_at、
is_deleted这类纯基础设施字段作为业务对象属性——它们属于 ORM 层或仓储层职责，OOP 模型里不该感知。
id、
created_at、
version等由仓储/ORM 自动管理，不进领域对象
user_id在 Order 类里应表现为
userId: UserId（值对象），而非 int 金额类字段必须用
Money值对象封装，避免
float精度丢失和单位混淆
怎么让 MySQL 表结构支持领域事件和状态快照？
不要给每张业务表加一堆
before_status、
event_type字段。正确做法是分离：主表只存当前权威状态（如
orders表），另建独立的
order_events表记录每次变更（含
event_type、
payload JSON、
occurred_at）；需要快照时，用定时任务或 CDC 工具（如 Debezium）从事件流重建，而不是在业务代码里手动
INSERT INTO order_snapshots ... SELECT *。这样既避免主表膨胀，又保留完整溯源能力。
CREATE TABLE order_events ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, event_type VARCHAR(64) NOT NULL, -- 'ORDER_CREATED', 'PAYMENT_SUCCEEDED' payload JSON NOT NULL, occurred_at DATETIME(6) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
外键约束和领域聚合边界冲突怎么办？
MySQL 外键是物理一致性保障，但会绑架领域模型的演进节奏。例如订单与商品解耦后，
order_items.product_id不再指向
products.id，而是指向
catalog_snapshots.id（快照表）。此时若强行加外键，会导致快照表无法归档、商品下架失败。解决方式是：在应用层用
Repository和
Domain Service保证逻辑一致性（如创建订单前校验商品快照是否存在），数据库层仅对强依赖关系（如
order_id → orders.id）保留外键，其余用注释 + 测试覆盖代替。 聚合根内部强一致性用外键（如
order_items.order_id → orders.id） 跨聚合引用一律用最终一致性 + 领域事件补偿（如订单完成触发「通知库存服务扣减」） 所有外键必须命名清晰，如
fk_order_items_order_id，禁止匿名约束
实际落地最难的不是语法或工具，是说服团队接受“数据库只管存，不管算”——只要有一处业务逻辑藏在触发器里，整个领域模型就失去了可测试性和可替换性。
