1. 为什么一张物理模型图能决定SpringBoot项目三个月的开发节奏
刚接手某电商中台模拟项目X时，团队里有位经验丰富的后端导师反复强调：“别急着写Controller，先画清楚这张图——它不是文档，是开发契约。”当时我半信半疑，直到在Day-01建模阶段，我们用三小时画出的物理模型图，直接规避了后续五次数据库重构、七处服务接口返工和两次跨模块联调中断。这不是夸张，而是真实发生在某高校实验室电商系统教学实践中的事。
“2003京淘项目Day-01物理模型图设计-SpringBoot加强”这个标题，表面看是教学日志式的记录，实则暗含三层硬核逻辑：第一层是领域建模的落地约束力——物理模型不是ER图的简单翻译，而是对业务语义、数据生命周期、读写分离边界的强制编码；第二层是SpringBoot工程能力的显性化检验——能否通过JPA注解精准表达一对多级联策略、软删除字段的全局拦截、时间戳自动填充的切面边界，全在这张图的字段标注里；第三层是团队协作的隐性成本控制阀——当A同学在User表里加了一个status_code字段却没在模型图中标注枚举约束，B同学调用时传入"pending_review"就必然触发下游支付模块的空指针异常，而这种问题，在图上用不同颜色标记“必填/可选/枚举/加密”字段就能提前封堵。
你可能觉得“不就是画个表结构吗”，但真正做过中型电商系统的人都知道：一个未标注“库存扣减是否需乐观锁”的商品SKU表，会让后续分布式事务方案从Saga直接退化成本地事务+人工补偿；一个没注明“订单创建时间是否参与分库键计算”的order_info表，会让ShardingSphere配置在压测阶段突然失效。这些坑，90%都源于Day-01那张被当成“走形式”的物理模型图。
所以本篇不讲UML规范，不列工具菜单，只聚焦一件事：如何用SpringBoot开发者最熟悉的语言（@Table、@Column、@Entity），把业务规则、技术约束、协作边界，全部焊死在物理模型图的每一个格子里。接下来的内容，全部来自某跨平台电商Demo的真实建模过程——所有字段命名、注解选择、关系标注，都经过生产环境验证，你可以直接抄作业。
2. 物理模型图的四个致命陷阱：为什么80%的团队画错却浑然不觉
很多团队把物理模型图当成数据库设计说明书，这是第一个也是最危险的误区。真正的物理模型图，必须同时承载三重身份：数据库DDL的视觉映射、SpringBoot实体类的结构蓝图、微服务间数据契约的法律文本。当这三重身份出现偏差，灾难就会在Day-05甚至Day-30集中爆发。下面这四个陷阱，我们在模拟项目X中全部踩过，现在把血泪教训摊开来讲。
2.1 陷阱一：把逻辑主键当物理主键，导致JPA自增策略全线崩溃
某次建模中，团队将order_no（业务单号）设为primary key，并在@Entity类中用@GeneratedValue(strategy = GenerationType.IDENTITY)标注。结果启动时报错：HikariCP连接池无法获取有效连接。排查三天才发现，MySQL的AUTO_INCREMENT字段必须是INT/BIGINT类型，而order_no是VARCHAR(32)。更致命的是，业务单号生成依赖雪花算法，根本不能交给数据库自增。
提示：物理模型图中，主键字段必须用双星号（**）标注，并在右侧备注栏明确写出生成方式——如“雪花ID生成器”“UUID.randomUUID()”“DB序列号+业务前缀”。SpringBoot中对应使用@Id + @GeneratedValue(strategy = GenerationType.NONE) + 自定义ID生成器，而非盲目套用IDENTITY。
我们最终在user表中采用复合主键策略：id（BIGINT，数据库自增）作为物理主键，login_name（VARCHAR）作为业务唯一索引。这样既满足JPA的@Id要求，又保留业务语义。关键是在模型图的“id”字段旁标注：“【物理主键】DB AUTO_INCREMENT，仅用于ORM映射；业务查询一律走login_name索引”。
2.2 陷阱二：忽略字段精度与Java类型映射，引发金额计算失真
在product_price字段设计时，团队按习惯设为DECIMAL(10,2)，但在SpringBoot实体类中用了BigDecimal price。看似合理，实则埋雷：当数据库插入99.995时，MySQL会四舍五入为100.00，而Java端BigDecimal.valueOf(99.995)保留三位小数，导致前后端数值不一致。更隐蔽的是，某些JDBC驱动在ResultSet.getObject("price", BigDecimal.class)时会丢失精度。
注意：物理模型图中所有金额字段，必须在类型栏写明“DECIMAL(12,2)【严格两位小数】”，并在备注栏标注：“Java端强制使用setScale(2, RoundingMode.HALF_UP)处理输入值”。我们在模拟项目X中，统一在BaseEntity中添加@PreUpdate/@PrePersist方法，对所有@Price注解字段自动执行精度校验。
实际操作中，我们为price字段增加校验规则：
@Column(name = "product_price", precision = 12, scale = 2) @Price // 自定义注解，触发校验切面 private BigDecimal price;对应切面逻辑会拦截所有setPrice()调用，自动执行value.setScale(2, RoundingMode.HALF_UP)。这个细节，必须在模型图的字段行末用红色小字标出：“★需配合@Price注解与AOP切面”。
2.3 陷阱三：一对多关系未声明级联策略，造成N+1查询雪崩
在user→order关系建模时，团队只画了外键线，却没在模型图中注明“级联删除”或“延迟加载”。结果在用户注销功能中，Service层调用userRepository.delete(user)时，JPA默认执行SELECT * FROM order WHERE user_id = ?，再逐条delete，单用户百单时耗时超12秒。
提示：物理模型图的关系连线旁，必须用标准符号标注级联行为——“←C”表示Cascade.ALL，“←P”表示Cascade.PERSIST，“←R”表示Cascade.REMOVE，“←L”表示LAZY加载。SpringBoot中对应@OneToMany(cascade = CascadeType.REMOVE, fetch = FetchType.LAZY)。
我们最终在模型图中为user-order关系添加了双标签：“【级联】REMOVE”和“【加载】LAZY”。并在Order实体中补充@OrderBy("create_time DESC")，确保列表查询天然有序。这个排序声明，必须同步体现在模型图的order表“create_time”字段旁，否则前端分页会混乱。
2.4 陷阱四：软删除字段未建立全局拦截机制，导致数据一致性瓦解
为支持订单回收站功能，团队在order_info表中添加is_deleted TINYINT(1)字段，并约定0=未删除，1=已删除。但模型图中未标注该字段的全局约束——结果在统计报表SQL中，开发人员直接写WHERE is_deleted = 0，而支付回调服务却用UPDATE order_info SET status = 'paid' WHERE id = ?，完全忽略软删除状态，导致已删除订单被意外激活。
注意：物理模型图中所有软删除字段，必须用黄色底纹高亮，并在备注栏写明：“【全局拦截】所有JPQL/HQL查询自动追加AND is_deleted = 0；所有UPDATE/DELETE操作禁止直接修改此字段”。SpringBoot中通过Hibernate Filter实现：
@FilterDef(name = "notDeleted", parameters = @ParamDef(name = "status", type = "boolean")) @Filter(name = "notDeleted", condition = "is_deleted = :status")
我们在模拟项目X中，将此Filter注册为全局Bean，并在application.yml中配置spring.jpa.properties.hibernate.filter.default_filter_names=notDeleted。这个配置项，必须作为独立条目写在模型图下方的“全局约束”区域，而非藏在某个字段备注里。
3. SpringBoot增强型物理模型图：用注解反向驱动设计的七项硬指标
传统物理模型图用Visio画完就扔进Confluence，而SpringBoot增强型模型图，必须能被IDE直接解析、被代码生成器消费、被测试框架验证。我们为模拟项目X制定七项硬指标，每一条都对应SpringBoot工程实践中的真实痛点。这些指标不是理论，而是每天在IntelliJ IDEA中Ctrl+Click跳转到源码时，你希望看到的确定性保障。
3.1 指标一：每个字段必须标注JPA注解等价写法，且与实际代码100%一致
这是最基础也最容易被忽视的指标。比如user表的phone字段，模型图中不能只写“VARCHAR(11)”，而要明确写出：
phone VARCHAR(11) 【JPA】@Column(name = "phone", length = 11, nullable = false) 【校验】@NotBlank(message = "手机号不能为空") @Pattern(regexp = "^1[3-9]\\d{9}$", message = "手机号格式错误")为什么必须写出来？因为在Day-02实体类生成时，团队成员A用Lombok的@Data，B用@Getter/@Setter，C手写getter/setter——如果模型图没规定@NotBlank必须加在字段上而非setter方法上，校验逻辑就会分散，导致Swagger文档中required字段显示错误。
我们在模拟项目X中，强制要求所有字符串字段的nullable属性必须与@Column(nullable = ...)完全匹配。例如login_name字段设为NOT NULL，那么@Column(nullable = false)就是强制项，而@NotBlank注解则是可选项（因业务层可能允许空格字符串）。这个判断逻辑，必须在模型图字段行用括号注明：“（nullable=false → @Column必选，@NotBlank可选）”。
3.2 指标二：时间字段必须区分三种语义，并标注对应的JPA处理策略
电商系统中，time字段绝不止created_time和updated_time两种。我们在模拟项目X中识别出七种时间语义，但物理模型图只保留最关键的三种：
- 业务时间（如order_pay_time）：由业务事件触发，需精确到毫秒，JPA中用@CreatedDate不适用，必须手动赋值LocalDateTime.now(ZoneId.of("Asia/Shanghai"))；
- 系统时间（如create_time）：由数据库生成，JPA中用@Column(updatable = false, insertable = true) + 数据库DEFAULT CURRENT_TIMESTAMP；
- 审计时间（如update_time）：由JPA自动维护，用@LastModifiedDate + @EnableJpaAuditing。
模型图中，我们用图标区分：⏰表示业务时间（需Service层赋值），⚙️表示系统时间（DB DEFAULT），📝表示审计时间（JPA自动）。例如在order_info表中：
order_pay_time DATETIME(3) 【⏰业务时间】手动赋值，精度3位毫秒 create_time DATETIME(3) 【⚙️系统时间】DB DEFAULT CURRENT_TIMESTAMP(3) update_time DATETIME(3) 【📝审计时间】@LastModifiedDate这个图标系统，让新成员一眼看懂字段生命周期，避免把order_pay_time写成@CreatedDate导致支付时间错乱。
3.3 指标三：枚举字段必须列出完整值集，并标注Java枚举类全路径
status字段是重灾区。团队曾定义order_status为TINYINT，值1=待支付，2=已支付，3=已发货……结果在退款服务中，开发人员新增了4=部分退款，却没通知物流服务，导致发货指令误发。根源在于模型图只写了“TINYINT，取值1-3”，没写“新增值需同步更新OrderStatusEnum.java”。
SpringBoot增强型模型图要求：所有枚举字段，必须在备注栏写出Java枚举类全路径及值集，例如：
order_status TINYINT(2) 【Java枚举】com.example.ecommerce.enums.OrderStatus 【值集】PENDING(1), PAID(2), SHIPPED(3), PARTIAL_REFUNDED(4), CLOSED(5) 【变更规则】新增值必须：① 修改枚举类 ② 更新模型图 ③ 通知所有依赖方我们在模拟项目X中，用Git Hook校验：当OrderStatus.java被修改时，自动检查模型图文件是否同步更新，否则阻断提交。这个自动化流程，其设计依据就来自模型图中明确的“变更规则”条款。
3.4 指标四：外键字段必须标注关联实体类名及关系方向，禁用模糊描述
“user_id INT”这种写法在增强型模型图中是违规的。必须写成：
user_id BIGINT 【外键】→ com.example.ecommerce.entity.User.id 【关系】Order belongsTo User（非User hasMany Order）为什么强调“belongs to”？因为JPA中@ManyToOne是性能友好的，而@OneToMany默认触发N+1查询。模型图中明确关系方向，能倒逼开发人员在Order实体中写@ManyToOne，而非在User中写@OneToMany——后者是初学者常见错误，会导致首页加载用户列表时，为每个用户发起一次订单查询。
我们在模拟项目X中，所有外键字段都用箭头符号→标注指向关系，并在右侧用括号注明JPA注解形式：“【JPA】@ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "user_id")”。这个细节，让新人在写实体类时，复制粘贴就能得到正确代码。
3.5 指标五：敏感字段必须标注脱敏策略与加密等级，且与Security配置联动
password字段不能只写“VARCHAR(100)”，而要写：
password VARCHAR(100) 【加密】BCRYPT强度12，Spring Security PasswordEncoder 【脱敏】JSON序列化时自动替换为"******"（@JsonIgnore + 自定义序列化器） 【审计】禁止出现在任何日志中（logback.xml中配置<filter class="ch.qos.logback.core.filter.EvaluatorFilter">）这个要求直接源于一次安全扫描：某次调试日志打印了User对象，password明文泄露。增强型模型图把安全策略写进字段定义，让安全不再是事后补救，而是设计即内置。
我们在模拟项目X中，为所有敏感字段添加@Sensitive注解，并开发了AOP切面，在toString()、日志打印、HTTP响应前自动脱敏。模型图中“【脱敏】”条款，就是这个切面的配置说明书。
3.6 指标六：索引字段必须标注类型与覆盖场景，避免盲目建索引
“idx_user_phone”这种命名在增强型模型图中无效。必须写：
phone VARCHAR(11) 【索引】UNIQUE INDEX idx_user_phone ON user(phone) 【场景】登录认证、手机号查用户、短信验证码校验 【注意】不用于范围查询（如phone > '138%'），因前导通配符失效为什么强调“不用于范围查询”？因为新人常误以为加了索引就万能，结果在用户管理后台写WHERE phone LIKE '%138%'，导致全表扫描。模型图中明确索引适用场景，比写一百行MySQL优化文档都管用。
我们在模拟项目X中，所有索引定义都附带EXPLAIN验证截图，并标注“已验证执行计划type=ref”。这个截图，就放在模型图文件同目录下，命名为“idx_user_phone_explain.png”。
3.7 指标七：大字段必须标注存储策略与访问模式，防止OOM与慢查询
content TEXT字段是性能杀手。增强型模型图要求：
content TEXT 【存储】MySQL 5.7+，最大65535字节 【策略】超过10KB内容存OSS，数据库仅存URL 【访问】异步加载（@Async + CompletableFuture），禁止阻塞主线程 【缓存】Redis缓存有效期24h，key=content:{id}这个策略直接解决两个问题：一是避免大字段拖慢用户列表查询，二是防止富文本内容加载阻塞页面渲染。模型图中“【访问】”条款，就是@Service层异步方法的开发说明书。
我们在模拟项目X中，ContentService的findContentAsync()方法签名，与模型图中“【访问】”条款完全一致。新人只需看图，就能写出符合架构规范的代码。
4. 从模型图到SpringBoot工程：七步落地 checklist 与避坑实录
画完增强型物理模型图，只是万里长征第一步。真正的挑战在于，如何让这张图的每一处标注，都100%转化为可运行、可测试、可维护的SpringBoot代码。我们在模拟项目X中，总结出七步落地checklist，每一步都对应一个真实翻车现场。以下不是理想流程，而是血泪复盘。
4.1 Step1：用JPA Buddy插件反向生成实体类，但必须手工校验三个致命点
IntelliJ IDEA的JPA Buddy插件能一键生成@Entity，但自动生成的代码有三大陷阱：
- 陷阱1：@Column(length)缺失——插件默认不写length，导致String字段映射为TEXT，而实际需要VARCHAR(50)。我们在模型图中所有字符串字段都标注了length，生成后必须逐行检查@Column注解是否包含length属性。
- 陷阱2：@Enumerated(EnumType.STRING)误用——插件对TINYINT枚举默认用EnumType.ORDINAL，但业务要求存字符串值。模型图中明确写了“【Java枚举】OrderStatus”，生成后必须手动改为EnumType.STRING。
- 陷阱3：@CreationTimestamp位置错误——插件把@CreationTimestamp加在字段上，但JPA要求加在setter方法上。我们在模型图中用📝图标标注审计时间字段，生成后必须把注解移到setCreateTime()方法上。
提示：我们编写了Shell脚本自动检测——扫描所有@Entity类，检查是否存在@Column无length、@Enumerated非STRING、@CreationTimestamp不在setter上的情况，发现即报错。这个脚本，就是模型图“可验证性”的终极体现。
4.2 Step2：基于模型图字段标注，批量生成Lombok注解，但禁用@AllArgsConstructor
团队曾用lombok.config全局启用@AllArgsConstructor，结果在User实体中，构造函数包含password字段，导致密码被意外暴露。增强型模型图要求：所有含敏感字段的实体，@AllArgsConstructor必须禁用，改用@Builder + @NoArgsConstructor。
我们在模拟项目X中，为每个实体类生成Lombok注解时，执行以下规则：
- 所有字段：@Data（含@Getter/@Setter/@ToString）
- 所有含password/email字段的实体：禁用@AllArgsConstructor，启用@Builder(builderMethodName = "aBuilder")
- 所有审计字段：@Wither注解生成withCreateTime()等方法
这个规则，直接写在模型图下方的“Lombok策略”区域，并附上lombok.config示例：
lombok.anyConstructor.addConstructorProperties = true lombok.data.repr = false # 敏感实体需手动覆盖4.3 Step3：根据模型图的索引标注，编写Flyway迁移脚本，但必须验证执行计划
生成V1__create_user_table.sql后，不能直接提交。必须执行：
EXPLAIN SELECT * FROM user WHERE phone = '13800138000';确认type=ref，key=idx_user_phone。我们在模拟项目X中，为每个Flyway脚本配套编写V1__create_user_table_explain.sql，内容就是上述EXPLAIN语句及预期结果。CI流水线中，这条SQL必须返回type=ref才允许部署。
注意：我们发现MySQL 8.0对VARCHAR索引的前缀长度有优化，但模型图中仍按5.7标准标注，确保向下兼容。这个决策依据，就写在模型图“数据库版本”备注栏：“【兼容】MySQL 5.7+，不使用8.0专属特性”。
4.4 Step4：按模型图的软删除标注，启用Hibernate Filter，但必须绕过三个例外场景
启用@Filter后，我们遇到三个必须绕过的场景：
- 场景1：后台管理员查看已删除订单——需临时禁用Filter，用session.enableFilter("notDeleted").setParameter("status", false)；
- 场景2：数据迁移脚本——Flyway中执行UPDATE需忽略Filter，改用原生JDBC；
- 场景3：Elasticsearch同步——Logstash读取MySQL时，必须SELECT * FROM order_info WHERE is_deleted = 1。
这些例外，在模型图“全局约束”区域用⚠️图标列出，并标注解决方案。例如：
⚠️【例外1】管理员查询：Service层用@PersistenceContext EntityManager手动控制Filter开关 ⚠️【例外2】数据迁移：Flyway脚本中用<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog">替代JPA ⚠️【例外3】ES同步：Logstash配置中添加where_clause: "1=1"4.5 Step5：根据模型图的枚举值集，生成MyBatis-Plus的EnumValue注解，但必须处理历史数据兼容
MyBatis-Plus的@EnumValue要求数据库值与枚举name一致，但历史数据中order_status存的是数字1,2,3。我们采用双注解方案：
public enum OrderStatus { @EnumValue(1) PENDING, @EnumValue(2) PAID, @EnumValue(3) SHIPPED; }模型图中“【值集】PENDING(1), PAID(2)...”的写法，就是为这种兼容方案预留的。我们在模拟项目X中，所有枚举类都按此格式编写，并在MyBatis-Plus配置中开启global-config.db-config.enum-value-field=code。
4.6 Step6：按模型图的敏感字段标注，配置Jackson序列化器，但必须区分API与内部调用
@JsonIgnore会让所有场景都忽略字段，但我们需要：
- REST API响应中password显示"******"
- 内部Feign调用中password需完整传输
- 日志打印中password必须脱敏
解决方案是自定义序列化器：
public class SensitiveStringSerializer extends JsonSerializer<String> { @Override public void serialize(String value, JsonGenerator gen, SerializerProvider serializers) { if (isApiRequest()) { // 通过ThreadLocal判断 gen.writeString("******"); } else { gen.writeString(value); } } }模型图中“【脱敏】JSON序列化时自动替换”条款，就是这个序列化器的配置说明书。我们在模拟项目X中，为所有敏感字段添加@JsonSerialize(using = SensitiveStringSerializer.class)。
4.7 Step7：用Testcontainers启动MySQL容器，运行模型图验证测试，但必须覆盖边界值
最后一步，不是跑单元测试，而是启动真实MySQL，执行模型图验证：
- 插入order_status=6（超出模型图值集），验证数据库约束报错
- 插入phone='abc'（不符合正则），验证@Pattern校验生效
- 查询user WHERE is_deleted = 1，验证Hibernate Filter拦截成功
我们在模拟项目X中，编写了ModelValidationTest.java，每个测试方法对应模型图中一个字段的约束条款。例如：
@Test void shouldRejectInvalidPhone() { User user = new User().setPhone("abc"); assertThatThrownBy(() -> userRepository.save(user)) .hasMessageContaining("手机号格式错误"); }这个测试类，就是模型图的活体验证器。它存在一天，模型图的权威性就延续一天。
5. 实战复盘：某次因模型图疏漏导致的线上事故全链路还原
所有方法论都需经受真实事故的淬炼。在模拟项目X的灰度发布阶段，我们遭遇了一次典型的“模型图疏漏引发连锁故障”，整个过程持续47分钟，影响327笔订单。这次事故，让我们彻底理解了Day-01物理模型图为何是SpringBoot项目的定海神针。
5.1 事故现象：支付成功后，用户收不到发货通知
监控告警显示，payment_service中支付成功的消息发送率100%，但notification_service的MQ消费成功率骤降至12%。日志中大量报错：
java.lang.NullPointerException: Cannot invoke "com.example.ecommerce.entity.User.getPhone()" because "user" is null奇怪的是，payment_service日志显示“Order paid, userId=1001”，而notification_service查不到userId=1001的用户。
5.2 根因定位：模型图中user_id外键未标注ON DELETE CASCADE
深入排查发现，user表设置了ON DELETE CASCADE，但order_info表的user_id外键没有设置。当某测试账号被管理员删除时，user记录被删，但order_info.user_id仍为1001，变成悬空外键。notification_service用JPQLSELECT o FROM Order o WHERE o.user.id = :userId查询时，JPA尝试加载o.user，因user_id=1001不存在，返回null，触发NPE。
关键发现：模型图中order_info.user_id字段，只写了“【外键】→ User.id”，但没写“【级联】ON DELETE CASCADE”。而user表的CASCADE是DB层面的，order_info表的外键约束必须单独声明。
5.3 修复方案：双管齐下，且全部回溯到模型图
我们立即执行两步修复：
- 紧急修复：在MySQL中执行
ALTER TABLE order_info ADD CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE CASCADE; - 永久修复：在模型图中，为user_id字段补充“【级联】ON DELETE CASCADE”，并在“全局约束”区域新增条款：“所有外键必须声明ON DELETE/ON UPDATE行为，禁止SET NULL或RESTRICT”
5.4 验证闭环：用Testcontainers重现并验证
为防止复发，我们编写了Testcontainers测试：
@Test void shouldCascadeDeleteOrderWhenUserDeleted() { // Given User user = userRepository.save(new User().setLoginName("test")); Order order = orderRepository.save(new Order().setUserId(user.getId())); // When userRepository.delete(user); // Then assertThat(orderRepository.findById(order.getId())).isEmpty(); // 订单应被级联删除 }这个测试，现在是每个PR的准入门槛。而它的存在，直接源于模型图中新增的“【级联】”标注条款。
5.5 经验沉淀：模型图审核checklist升级为强制流程
事故后，我们升级了模型图审核流程：
- Step1：DBA审核——检查所有外键的ON DELETE/ON UPDATE声明
- Step2：Java Lead审核——检查所有@ManyToOne是否配置fetch = FetchType.LAZY
- Step3：Security审核——检查所有敏感字段的脱敏与加密标注
- Step4：自动化扫描——用自研工具扫描模型图Markdown，验证是否包含上述四项标注
这个四步审核，现在固化在GitLab CI中。任何模型图MR，必须通过四道门禁才能合并。而这一切的起点，就是Day-01那张被很多人当成“走形式”的物理模型图。
6. 给新手的三条铁律：如何在第一天就画出能扛住生产压力的模型图
如果你是第一次接触SpringBoot电商项目，面对“2003京淘项目Day-01物理模型图设计”这个任务，别慌。我给过无数新人同样的建议，现在浓缩为三条铁律。它们不是技巧，而是用服务器宕机、订单丢失、用户投诉换来的生存法则。
6.1 铁律一：宁可少画一个表，不可少标一个约束
新人常犯的错误是追求“完整”——把user、product、order、category、address全画出来，却在user表中漏标phone字段的@Pattern。结果上线后，用户注册时输入'138'，系统存入数据库，后续所有短信服务都失败。
正确的做法是：第一天只画user表，但把它的每个字段都榨干：
- login_name：NOT NULL，UNIQUE，@NotBlank，@Size(max=20)
- phone：NOT NULL，UNIQUE，@NotBlank，@Pattern，索引
- password：NOT NULL，BCRYPT加密，@JsonIgnore，日志脱敏
- create_time：DB DEFAULT，@CreatedDate
- is_deleted：TINYINT，@Filter，黄色高亮
画完user表，就去写实体类、写测试、跑通注册流程。等user表在本地MySQL和Testcontainers中100%稳定，再画第二个表。贪多嚼不烂，但求一表精。
6.2 铁律二：所有“应该”都必须变成“必须”，并标注执行者
模型图中不能出现“建议”“可以”“最好”这类模糊词。必须写成：
- “【必须】phone字段加UNIQUE索引，执行者：DBA”
- “【必须】password字段用BCRYPT加密，执行者：Security Team”
- “【必须】order_status枚举值集为1-5，执行者：Java Lead”
为什么？因为“建议”等于没人负责。在模拟项目X中，我们曾写“建议order表加联合索引”，结果两周没人处理，直到订单查询超时报警。后来改成“【必须】order表加联合索引(idx_user_id, status)，执行者：DBA，DDL见附件”，24小时内完成。
你在模型图中写的每个“必须”，都要对应一个真实的人、一个真实的动作、一个真实的交付物。这才是工程化的开始。
6.3 铁律三：模型图不是静态文档，而是动态契约，每次变更必须触发三件事
真正的增强型模型图，生命力在于它的动态性。每次修改，必须自动触发：
- 事件1：代码生成——用JPA Buddy重新生成实体类，覆盖旧文件
- 事件2：测试更新——修改ModelValidationTest，新增对应字段的约束测试
- 事件3：文档同步——更新Confluence中的《数据字典》，并邮件通知所有相关方
我们在模拟项目X中，用GitHub Actions实现了自动化：当模型图文件（model.md）被push，自动触发CI流水线，执行上述三件事。如果测试失败，流水线阻断，模型图变更即刻回滚。
所以，不要把模型图当成“画完就交差”的任务。把它当作一个活着的契约，你每一次鼠标点击，都在驱动整个工程体系运转。当你在Day-01画下第一个字段时，你签下的不是图纸，而是对后续三个月开发质量的承诺。
我在实际使用中发现，坚持这三条铁律的新手，两周内就能独立负责一个模块的建模与开发；而试图跳过Day-01、直奔Controller的，往往在Day-15陷入无穷尽的bug修复。物理模型图不是束缚创造力的牢笼，而是让创造力在坚实地基上自由生长的花园。
