如何用ER图清晰划分费用报销系统三域？

Question

在设计费用报销系统的ER图时，如何清晰划分业务域、数据域与权限域是一大技术难点。常见问题是：三域实体边界模糊，导致“报销单”等核心实体既包含业务流程属性，又混杂数据存储字段和用户权限控制信息，造成模型冗余与维护困难。此外，域间关联关系不明确，如权限域的“角色”实体与业务域的“审批流”缺乏清晰映射，影响系统扩展性。如何通过ER图准确体现三域分离又协同的结构，是保障系统可维护性与安全性的关键挑战。

Answer 1

一、问题背景与核心挑战

在设计费用报销系统的ER图时，如何清晰划分业务域、数据域与权限域成为关键的技术难点。随着企业数字化进程的深入，报销系统不仅要支持复杂的审批流程，还需满足高安全性和可扩展性的要求。

常见问题是三域实体边界模糊，例如“报销单”实体常同时包含：

• 业务属性（如报销类型、事由、金额）
• 数据存储字段（如创建时间、更新日志）
• 权限控制信息（如申请人ID、审批人角色）

这种混杂导致模型冗余、变更成本高，并影响后期维护与审计合规性。

二、从浅入深：三域分离的设计演进路径

1. 初级阶段：单一实体承载多职责 —— 报销单直接关联用户和角色，缺乏抽象层。
2. 中级阶段：初步解耦业务与数据 —— 引入“报销单头”与“明细”表，但权限仍嵌入业务表。
3. 高级阶段：明确三域边界 —— 使用领域驱动设计（DDD）思想，划分限界上下文。
4. 成熟阶段：通过ER图显式表达域间协作 —— 利用外键约束与关联表实现松耦合。
5. 优化阶段：支持动态权限与可配置流程 —— 权限域独立建模，支持RBAC/ABAC混合模式。

三、三域划分的逻辑结构定义

域类别	核心实体	主要属性	职责说明
业务域	报销单、审批流实例、费用类型	金额、事由、状态、流程节点	描述业务行为与流程流转
数据域	操作日志、附件元数据、版本快照	创建时间、修改人、文件路径	支撑数据持久化与审计追踪
权限域	角色、权限策略、访问控制列表	资源URI、操作类型、生效范围	控制谁能在何时执行何种操作

四、典型问题分析过程

以“报销单审批失败因权限变更”为例：

1. 现象：用户A提交报销单后，原审批人B离职，新审批人C未自动接管。
2. 根因分析：审批人字段硬编码在“报销单”表中，未通过“角色-岗位-流程节点”映射解耦。
3. 数据域缺失：无“审批历史”记录，无法追溯责任链。
4. 权限域孤立：角色变更未触发流程引擎重计算。
5. 结论：需建立“流程模板→角色→实际执行人”的动态绑定机制。

五、解决方案设计：基于ER图的三域协同架构

-- 业务域核心表
CREATE TABLE expense_report (
    id BIGINT PRIMARY KEY,
    type VARCHAR(50),
    amount DECIMAL(10,2),
    status VARCHAR(20),
    current_node VARCHAR(50),
    flow_instance_id BIGINT
);

-- 数据域支撑表
CREATE TABLE operation_log (
    id BIGINT PRIMARY KEY,
    entity_type VARCHAR(50),
    entity_id BIGINT,
    operator_id BIGINT,
    action VARCHAR(20),
    timestamp DATETIME
);

-- 权限域核心表
CREATE TABLE role_permission (
    role_id BIGINT,
    resource_type VARCHAR(50),
    action VARCHAR(20),
    constraint_expression TEXT,
    PRIMARY KEY (role_id, resource_type, action)
);

    

六、ER图中的域间关系可视化表达

使用Mermaid语法绘制三域交互结构：

erDiagram
            USER ||--o{ ROLE : has
            ROLE ||--o{ PERMISSION : defines
            USER ||--o{ EXPENSE_REPORT : creates
            EXPENSE_REPORT }|--|| APPROVAL_FLOW_INSTANCE : "runs"
            APPROVAL_FLOW_INSTANCE }|--|| FLOW_NODE : "current"
            FLOW_NODE }|--|| ROLE : "requires"
            EXPENSE_REPORT }|--|| OPERATION_LOG : generates
            OPERATION_LOG }|--|| USER : records

七、关键设计原则总结

• 单一职责原则：每个实体仅属于一个域，避免跨域属性污染。
• 引用代替嵌入：审批人用user_id而非直接存姓名或角色名。
• 事件驱动联动：权限变更应发布事件，通知流程引擎刷新上下文。
• 元数据驱动配置：审批流模板可配置化，绑定角色而非具体人员。
• 审计完整性：所有状态变更必须生成operation_log记录。
• 扩展预留字段：在数据域中预留context_data JSON字段用于未来扩展。
• 软删除机制：业务域实体不物理删除，保障历史数据一致性。
• 版本化管理：报销单结构变更时保留旧版schema映射规则。
• 跨域索引优化：在高频查询路径上建立复合索引（如 user_id + status）。
• 安全脱敏设计：敏感字段（如银行卡号）在数据域单独加密存储。