企业官网建设流程全解析

1. 为什么“需求分析”在分层架构里不是第一步，而是最危险的一步？

很多人看到“基于.NET平台的分层架构实战（二）——需求分析与数据库设计”这个标题，第一反应是：“哦，这是讲怎么画UML图、写用例文档、做ER图的”。我试过三次——第一次在某高校实验室带学生做模拟项目X，第二次在某公司参与某跨平台系统重构，第三次是帮A同学辅导毕业设计——每次都是刚打开Visio或PowerDesigner，不到两小时就陷入僵局：业务方说“要能查订单”，开发说“那得建Order表”，测试问“退货单算不算订单”，运维补一句“日均50万单，索引怎么建？”——所有人对着同一张“需求文档”各说各话。

这不是沟通问题，是分层架构语境下“需求”本身的定义被偷换了。在传统瀑布模型里，“需求分析”产出的是静态契约；但在分层架构中，它必须是可验证的分层契约：UI层关心“用户点击后3秒内看到结果”，Application层关心“能否在200ms内完成订单状态变更”，Domain层关心“订单生命周期是否满足‘创建→支付→发货→完成’不可逆约束”，Infrastructure层则只认“SQL Server 2019+、主键必须是GUID、所有外键强制级联删除”。

我见过最典型的翻车案例，是某导师指导的模拟项目X。团队花三周时间把“用户管理”需求拆成17个用例，画了42张活动图，最后在实现Repository接口时卡住：因为用例里写着“管理员可批量禁用用户”，但Domain层实体User根本没有IsEnabled属性——它被设计成“软删除+状态机”，而状态机流转规则要求“禁用前必须先冻结”。这根本不是数据库字段缺失的问题，是需求描述没有绑定到具体分层的责任边界上。

所以本篇不讲“如何写需求文档”，而是聚焦三个实操铁律：

• 第一，所有需求陈述必须标注分层归属。例如“用户登录失败5次后锁定账户”不能只写在PRD里，必须明确标注为Domain层规则（触发AccountLockedDomainEvent），Infrastructure层只负责持久化LockUntil字段；
• 第二，数据库设计不是需求分析的终点，而是Domain模型落地的第一道压力测试。一张表的设计缺陷，会在Application层暴露为事务边界混乱，在UI层表现为“保存成功但列表不刷新”；
• 第三，拒绝“伪需求”。像“系统要支持高并发”这种描述毫无意义，必须转化为可测量的分层指标：Infrastructure层要求“单节点支撑5000 TPS”，Application层要求“OrderService.CreateAsync方法P99<150ms”，Domain层则要求“同一用户ID的并发创建请求必须串行化”。

提示：在开始画任何ER图前，先用一句话写下该实体在Domain层的核心不变量（Invariant）。例如User实体的不变量是“Email格式合法且全局唯一”，Order实体的不变量是“TotalAmount = Sum(Item.Price × Item.Quantity) + ShippingFee - Discount”。如果写不出来，说明需求还没穿透到Domain层。

这直接决定了后续所有技术决策：Entity Framework Core的配置方式、仓储接口的粒度、CQRS是否启用、甚至DTO的字段命名。我们接下来就从一个真实踩坑场景切入——某跨平台系统的“商品库存”需求，看它是如何从一句模糊的“要能实时显示库存”演变成四张表、七个约束、三个领域事件的。

2. “实时库存”需求背后的三层绞杀：从口头承诺到数据库DDL

去年参与某公司某跨平台系统重构时，业务方拍板定调：“库存必须实时，用户加购时看到的数字，就是下单时能买到的数量。”这句话在会议室引发短暂掌声，转头就让整个技术组失眠两周。表面看是Infrastructure层的缓存一致性问题，深挖下去才发现，是Domain层、Application层、Infrastructure层三重逻辑在互相撕扯。

2.1 Domain层：库存不是数字，而是状态机

业务说的“库存数字”，在Domain层根本不存在。我们定义的实体是InventoryItem，它有四个关键状态：Available（可售）、Reserved（已预占）、Committed（已成交）、Blocked（风控拦截）。真正的“实时库存”其实是Available - Reserved的计算结果，而这个计算绝不能由数据库视图或SQL聚合完成——因为Reserved状态需要关联到具体的购物车会话（SessionId），而会话生命周期远短于数据库事务。

我们最终确定的Domain不变量有三条：

1. Available初始值等于采购入库数量，只允许通过InventoryItem.IncreaseAvailable()方法增加；
2. Reserved只能通过InventoryItem.ReserveForCart(string cartId, int quantity)创建，且必须满足Available >= quantity；
3. Committed仅能由InventoryItem.CommitReservation(string cartId)触发，此时Reserved对应数量转入Committed，Available同步扣减。

这意味着，哪怕数据库里只存Available和Reserved两个字段，Domain层也天然隔离了“超卖”风险——因为ReserveForCart方法内部会校验余额，而校验逻辑封装在实体内部，无法绕过。

2.2 Application层：事务边界决定数据库表结构

当Domain层把库存逻辑锁死，Application层的任务就变成：如何让这些Domain操作在分布式环境下原子执行？我们否决了“单库单表+乐观锁”的方案，原因很现实：某跨平台系统要求支持多仓库库存池（华东仓、华南仓、海外仓），而每个仓库的库存变动频率差异极大。如果强行用一张Inventory表存所有仓库数据，热点更新会导致SQL Server锁升级为页锁，TPS暴跌40%。

最终采用分库分表策略，但分片键不是WarehouseId，而是InventoryItemId的哈希值——因为业务查询80%是“查某商品在所有仓库的可用库存”，而非“查某仓库所有商品库存”。于是Application服务InventoryAppService的ReserveStockAsync方法长这样：

public async Task<bool> ReserveStockAsync(Guid inventoryItemId, string cartId, int quantity) { // 1. 根据inventoryItemId路由到对应分片库 var db = _shardRouter.GetDatabase(inventoryItemId); // 2. 在Domain层执行预留逻辑（含校验） var item = await db.InventoryItems.FindAsync(inventoryItemId); if (!item.ReserveForCart(cartId, quantity)) return false; // Domain层已拒绝超卖 // 3. 持久化变更（注意：此处不提交事务！） await db.SaveChangesAsync(); // 4. 发布领域事件，触发下游库存扣减通知 await _eventBus.PublishAsync(new InventoryReservedEvent(inventoryItemId, cartId, quantity)); return true; }

这个设计倒逼数据库必须支持跨分片的最终一致性，因此我们放弃了SQL Server的分布式事务（DTC），改用本地消息表+定时扫描。这也直接决定了InventoryItem表的结构：必须包含LastModifiedUtc字段用于消息表去重，Version字段用于乐观并发控制，且Reserved字段类型必须是jsonb（PostgreSQL）或nvarchar(max)（SQL Server），以存储动态的{ "cartId": "abc", "quantity": 2 }数组——因为一个商品可能被多个购物车同时预占。

2.3 Infrastructure层：数据库设计是Domain模型的镜像，不是业务描述的翻译

基于上述分层约束，我们最终敲定的数据库设计完全颠覆了传统思路：

特别注意ReservedData字段的设计。传统做法是建InventoryReservations关联表，但这样会导致：

• 查询“某商品剩余可用库存”需SELECT Available - SUM(quantity) FROM InventoryReservations WHERE ItemId = @id，在高并发下SUM成为性能瓶颈；
• 删除过期购物车时，需DELETE FROM InventoryReservations WHERE CartId IN (...)，大表扫描拖垮IO；
• 更致命的是，InventoryItem实体的状态校验逻辑（如ReserveForCart）必须依赖外部查询，违反了Domain层“自我完备”的原则。

而JSON字段方案让Domain层校验完全内存化：ReserveForCart方法加载ReservedData后，直接反序列化为List<Reservation>，遍历计算总预占量，全程不触碰数据库。只有校验通过后，才更新ReservedData字段——这正是分层架构要求的“Domain层不依赖Infrastructure”的具象体现。

注意：SQL Server 2019+对JSON字段的索引支持有限，我们通过在InventoryItems表上添加计算列ReservedSum AS JSON_VALUE(ReservedData, '$.total')并为其建索引，解决高频查询场景。但计算列无法在UPDATE语句中自动维护，因此必须在Application层确保每次更新ReservedData时，同步更新ReservedSum字段——这再次证明，数据库设计永远是分层协作的结果，而非单点决策。

3. 数据库设计的五道生死线：那些教科书不会写的硬约束

很多开发者以为数据库设计就是“把类属性转成字段，加个主键，再按范式拆表”。在分层架构下，这无异于给Domain模型套上镣铐跳舞。我整理出五条在某跨平台系统、模拟项目X等实战中反复验证的硬约束，每一条都曾导致线上事故或返工。

3.1 主键必须是业务无关的GUID，且永不暴露给UI层

这是.NET分层架构的铁律。有人质疑：“用自增ID更省空间，查询更快”。但请看真实案例：某导师指导的模拟项目X上线后，运营部门要求导出“近30天创建的所有订单”，DBA写了SELECT * FROM Orders WHERE Id > 1000000 AND CreatedAt > '2024-01-01'——结果漏掉大量数据。因为Id是自增，但订单创建是分布式服务生成，不同节点ID不连续，Id > 1000000实际过滤的是“最后一批插入的订单”，而非“最新创建的订单”。

GUID主键彻底规避此问题，但带来新挑战：索引碎片。我们的解决方案是组合主键：Id（GUID）作为逻辑主键，CreatedAt（DATETIME2）作为聚集索引键。SQL Server建表语句如下：

CREATE TABLE Orders ( Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID(), CreatedAt DATETIME2 NOT NULL DEFAULT GETUTCDATE(), -- 其他字段... CONSTRAINT PK_Orders PRIMARY KEY NONCLUSTERED (Id), CONSTRAINT IX_Orders_CreatedAt CLUSTERED (CreatedAt DESC, Id) );

这样既保证Id全局唯一且无序（避免热点），又让CreatedAt范围查询走聚集索引。更重要的是，Id字段绝不作为DTO属性返回给前端。UI层看到的“订单号”是独立的OrderNumber字段（格式如ORD-20240520-00001），由Application层在创建订单时生成，并持久化到数据库。这确保了Domain层可以自由更换ID生成策略（比如未来切到Snowflake算法），而不影响任何外部系统。

3.2 外键必须显式声明，且级联行为由Domain层控制

“数据库外键影响性能，干脆不用”的观点极其危险。某公司某跨平台系统曾因删除用户时未清理其订单，导致报表统计异常。DBA的补救方案是在Application层加DeleteUserWithOrdersAsync方法，但很快发现：

• 订单表有CreatedByUserId和UpdatedByUserId两个外键，需分别处理；
• 订单关联的支付记录、物流单又指向其他用户，形成链式依赖；
• 最终代码变成嵌套的foreach循环，一次删除耗时2秒以上。

正确解法是在数据库层面声明外键，但禁用级联删除（ON DELETE NO ACTION），将删除逻辑收归Domain层。User实体的DeleteAsync方法长这样：

public async Task DeleteAsync() { // 1. Domain层校验：用户是否有未完成订单？ if (await _orderRepository.HasActiveOrdersAsync(this.Id)) throw new BusinessRuleViolationException("用户存在未完成订单，禁止删除"); // 2. 标记用户为Deleted（软删除） this.Status = UserStatus.Deleted; this.DeletedAt = DateTime.UtcNow; // 3. 持久化（此时外键约束确保关联数据未被破坏） await _userRepository.UpdateAsync(this); }

数据库外键的作用是兜底防护：即使Application层代码出错（比如忘记调用HasActiveOrdersAsync），INSERT/UPDATE操作也会因外键约束失败，而不是留下脏数据。而级联行为交给Domain层，是因为只有它理解业务语义——“删除用户”不等于“删除其所有订单”，可能是“转移订单归属”或“归档订单”。

3.3 时间字段必须区分UTC与本地时区，且UTC字段不可为空

.NET的DateTime类型有Kind属性，但数据库字段没有。某高校实验室的模拟项目X曾出现诡异Bug：后台任务每天凌晨2点生成报表，但某天报表数据为空。排查发现，服务器时区设为Asia/Shanghai，而DateTime.Now生成的时间存入数据库后，Kind变为Unspecified，EF Core读取时默认按本地时区解析，导致WHERE CreatedAt > '2024-05-20 02:00:00'实际匹配的是2024-05-20T02:00:00+08:00，而非UTC时间。

解决方案是强制约定：

• 所有表示“绝对时间点”的字段（如CreatedAt,UpdatedAt,ProcessedAt）必须是DATETIME2类型，且应用层一律使用DateTime.UtcNow赋值；
• 所有表示“本地时间”的字段（如User.PreferredWakeUpTime）必须是TIME类型，并额外增加TimeZoneId（VARCHAR）字段存储时区标识（如"Asia/Shanghai"）；
• 数据库表结构中，CreatedAt字段必须有DEFAULT GETUTCDATE()约束，且NOT NULL。

EF Core配置示例：

modelBuilder.Entity<Order>() .Property(e => e.CreatedAt) .HasDefaultValueSql("GETUTCDATE()") .ValueGeneratedOnAdd();

这确保了时间数据的可追溯性：任何时间点都能精确还原到UTC，再根据用户时区转换为本地时间展示。

3.4 枚举字段必须用整数存储，且数据库约束与Domain层枚举严格同步

用字符串存枚举（如Status NVARCHAR(20)）看似直观，实则埋雷。某公司某跨平台系统曾将订单状态从"Pending"改为"AwaitingPayment"，结果所有历史数据丢失语义，报表查询全部失效。

正确做法是整数+CHECK约束+Domain层映射：

CREATE TABLE Orders ( Id UNIQUEIDENTIFIER NOT NULL, Status TINYINT NOT NULL CHECK (Status IN (0, 1, 2, 3, 4)), -- 0=Created, 1=Paid, 2=Shipped, 3=Completed, 4=Cancelled -- ... );

Domain层枚举：

public enum OrderStatus : byte { Created = 0, Paid = 1, Shipped = 2, Completed = 3, Cancelled = 4 }

EF Core配置：

modelBuilder.Entity<Order>() .Property(e => e.Status) .HasConversion<byte>(); // 直接映射到TINYINT

这样做的好处是：

• 数据库体积最小（TINYINT仅1字节）；
• 查询性能最优（整数比较快于字符串）；
• 业务变更安全（新增状态只需扩展枚举和CHECK约束，不影响历史数据）；
• 领域事件序列化稳定（JSON中存数字而非字符串，避免大小写歧义）。

3.5 敏感字段必须加密存储，且密钥轮换机制写死在Infrastructure层

密码、手机号、身份证号等敏感字段，绝不能依赖“应用层加密+数据库明文存储”。某导师指导的模拟项目X曾用AES加密手机号，密钥硬编码在Config文件中，结果一次服务器漏洞导致密钥泄露，全库手机号被解密。

我们的方案是双层加密：

• 第一层：应用层使用IDataProtector（ASP.NET Core内置）对敏感字段加密，密钥由ASP.NET Core Data Protection API管理，自动轮换；
• 第二层：Infrastructure层在数据库中对加密后的密文再进行一次AES-GCM加密，密钥由Azure Key Vault托管，应用启动时动态获取。

数据库字段设计：

Infrastructure层的UserRepository在Save时调用：

private byte[] DoubleEncrypt(byte[] plainText) { // 第一层：应用层加密（IDataProtector） var protectedText = _protector.Protect(plainText); // 第二层：基础设施层加密（Azure Key Vault密钥） var key = _keyVaultClient.GetKeyAsync("user-phone-key").Result; return AesGcmEncrypt(protectedText, key, out var iv, out var tag); }

这种设计确保：即使数据库被拖库，攻击者也无法解密；即使应用服务器被入侵，没有Key Vault权限仍无法解密。密钥轮换时，只需更新Key Vault中的密钥，旧密文仍可通过密钥版本追溯解密。

4. 从需求到DDL的完整推演：以“用户积分体系”为例的逐层拆解

前面讲了原则和陷阱，现在用一个完整案例演示如何从零开始，把一句模糊的业务需求，一步步推演成可落地的数据库设计。这个案例来自某公司某跨平台系统的“用户积分”模块，需求原文只有两句话：“用户消费1元得1积分，积分可兑换商品。”

4.1 Domain层建模：识别核心实体与不变量

首先剥离技术术语，直击业务本质：

• “消费1元得1积分” → 积分是消费行为的副产品，必须与订单强绑定；
• “积分可兑换商品” → 积分是独立资产，有生命周期（获得、冻结、使用、过期）。

由此识别出三个Domain实体：

• Order：消费行为载体，产生积分的源头；
• PointBalance：用户积分余额，核心不变量是“可用积分 = 总积分 - 已冻结积分 - 已使用积分”；
• PointTransaction：积分变动记录，必须不可变、可追溯。

PointBalance的不变量尤为关键：

1. TotalPoints只能通过Order完成事件增加；
2. FrozenPoints只能通过PointTransaction类型为Freeze的记录增加；
3. UsedPoints只能通过PointTransaction类型为Use的记录增加；
4. AvailablePoints = TotalPoints - FrozenPoints - UsedPoints，且AvailablePoints >= 0。

这意味着，PointBalance不能简单设计为一张表存四个字段，因为AvailablePoints是计算值，不应持久化——否则会因并发更新导致数据不一致。

4.2 Application层设计：事务边界与幂等性保障

积分变动必须满足ACID，但Order和PointTransaction可能跨服务。我们采用Saga模式：

• 订单服务创建订单后，发布OrderCreatedEvent；
• 积分服务监听事件，创建PointTransaction记录（类型Earn），并更新PointBalance；
• 若更新失败，发送CompensatePointEarnEvent，订单服务回滚订单。

为保障幂等性，PointTransaction表必须有唯一约束：

CREATE TABLE PointTransactions ( Id BIGINT IDENTITY PRIMARY KEY, TransactionId UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID(), -- 业务ID，全局唯一 UserId UNIQUEIDENTIFIER NOT NULL, OrderId UNIQUEIDENTIFIER NULL, -- 关联订单 Type TINYINT NOT NULL, -- 0=Earn, 1=Freeze, 2=Use, 3=Expire Points INT NOT NULL, CreatedAt DATETIME2 NOT NULL DEFAULT GETUTCDATE(), CONSTRAINT UQ_PointTransactions_TransactionId UNIQUE (TransactionId), CONSTRAINT FK_PointTransactions_UserId FOREIGN KEY (UserId) REFERENCES Users(Id) );

TransactionId是业务方生成的唯一ID（如订单号+操作类型哈希），确保同一次订单创建，无论重试多少次，只产生一条积分记录。

4.3 Infrastructure层落地：表结构与索引策略

基于Domain和Application层约束，最终数据库设计如下：

PointBalances表（用户积分余额快照）

PointTransactions表（积分流水）

关键索引策略：

• PointBalances表：UserId为主键，无需额外索引；
• PointTransactions表：建立复合索引IX_PointTransactions_UserId_Type_CreatedAt，支持“查某用户某类型积分流水（按时间倒序）”的高频查询；
• 为加速AvailablePoints计算，添加计算列AvailablePoints AS TotalPoints - FrozenPoints - UsedPoints并建索引，但仅用于查询，不参与业务逻辑——Domain层计算仍走内存。

4.4 验证与反推：用数据库设计倒逼Domain模型完善

设计完成后，我们用数据库约束反推Domain模型是否完备：

• PointBalances表没有AvailablePoints字段 → 证明Domain层必须提供CalculateAvailablePoints()方法；
• PointTransactions表OrderId允许NULL → 说明存在非订单来源的积分（如签到奖励），Domain层需支持EarnPointsWithoutOrder()方法；
• Type字段的CHECK约束包含Expire→ 要求Domain层实现积分过期规则，如“12个月内未使用自动清零”。

这正是分层架构的威力：数据库不是需求的终点，而是Domain模型的试金石。每一次DDL修改，都在提醒我们：“你的领域模型，是否真的覆盖了所有业务边界？”

提示：在编写EF Core Fluent API配置时，务必把数据库约束（CHECK、UNIQUE、FOREIGN KEY）全部声明出来。例如：

modelBuilder.Entity<PointTransaction>() .HasIndex(e => e.UserId) .HasDatabaseName("IX_PointTransactions_UserId"); modelBuilder.Entity<PointTransaction>() .HasCheckConstraint("CK_PointTransaction_Type", "Type IN (0,1,2,3)");

这样生成的迁移脚本（dotnet ef migrations add Init）会自动包含SQL约束，避免手动编写DDL遗漏。

5. 实战避坑指南：那些让我通宵改Schema的血泪教训

数据库设计不是一锤定音的静态产物，而是在迭代中不断修正的活文档。以下是我在某跨平台系统、模拟项目X等项目中，因忽略分层视角导致的典型翻车现场，以及对应的止血方案。

5.1 坑：用“通用字段”应对需求变更，结果通用成灾难

某导师指导的模拟项目X初期，为应对“未来可能增加用户标签”的需求，设计了Users表的ExtraData NVARCHAR(MAX)字段，存JSON格式的扩展属性。上线后业务方要求“按VIP等级筛选用户”，开发直接写WHERE JSON_VALUE(ExtraData, '$.vipLevel') = 5——结果全表扫描，查询耗时从20ms飙升到8秒。

止血方案：

• 立即停止在ExtraData中存查询字段，新建UserProfiles表，将vipLevel、preferredLanguage等高频查询字段拆出；
• 对ExtraData字段添加全文索引（SQL Server）或GIN索引（PostgreSQL），仅支持CONTAINS(ExtraData, 'keyword')类模糊搜索；
• 在Domain层抽象IUserProfileService，统一管理扩展属性的读写，避免业务代码直操作JSON。

根本解法：在需求分析阶段，对每个“可能扩展”的字段，问三个问题：

1. 该字段是否会被WHERE条件查询？→ 是，则必须单独建字段；
2. 该字段是否会被GROUP BY或ORDER BY？→ 是，则必须单独建字段+索引；
3. 该字段是否属于某个子领域（如“营销标签”）？→ 是，则应建独立子领域表，而非塞进主表。

5.2 坑：忽略读写分离，写库扛不住报表查询

某公司某跨平台系统上线后，运营部门每天上午9点跑“昨日销售TOP100”报表，直接连主库，导致下单接口P99延迟从120ms涨到1.2秒。DBA的临时方案是加索引，但报表SQL含JOIN和GROUP BY，索引效果甚微。

止血方案：

• 立即切流：报表查询路由到只读副本，主库专注写操作；
• 在只读副本上建物化视图（SQL Server）或汇总表（如DailySalesSummary），预计算聚合结果；
• Application层ReportService不再直接查订单表，而是查汇总表。

根本解法：在数据库设计初期，就规划读写分离策略。Orders表结构增加IsProcessedForReporting BIT DEFAULT 0字段，Application层在订单完成时，异步更新该字段并触发报表计算。Infrastructure层通过CDC（Change Data Capture）捕获IsProcessedForReporting = 1的变更，自动同步到报表库。

5.3 坑：用DateTime.Now存时间，跨时区服务数据错乱

某高校实验室的模拟项目X部署在三台服务器，分别位于北京、上海、深圳。用户在北京下单，订单CreatedAt存的是DateTime.Now（本地时间），结果上海服务器读取时，CreatedAt被解析为2024-05-20 09:00:00+08:00，而深圳服务器解析为2024-05-20 09:00:00+08:00——看似一样，但EF Core的DateTime比较逻辑会因Kind不同而结果异常。

止血方案：

• 紧急发布补丁：所有DateTime.Now替换为DateTime.UtcNow；
• 批量修正历史数据：用AT TIME ZONE函数将现有时间转换为UTC（SQL Server 2016+）；
• 在EF Core中全局配置UseUtcForTimeStamps()。

根本解法：在项目初始化时，强制约定所有时间操作。我们在Program.cs中加入：

// 强制所有DateTime属性映射为UTC AppContext.SetSwitch("Npgsql.EnableLegacyTimestampBehavior", true); // 或 SQL Server modelBuilder.Entity<Order>().Property(e => e.CreatedAt).HasDefaultValueSql("GETUTCDATE()");

并制定《时间处理规范》：

• 所有表示“事件发生时间”的字段，必须用DateTime.UtcNow；
• 所有表示“用户期望时间”的字段（如预约时间），必须存DateTime+TimeZoneId；
• 前端传时间，必须带时区信息（ISO 8601格式），后端统一转UTC存储。

5.4 坑：外键没建，靠代码维护关联，结果数据孤儿遍地

某公司某跨平台系统早期，为“提升性能”取消了OrderItems表对Orders表的外键。半年后，DBA执行DELETE FROM Orders WHERE Status = 'Draft'清理草稿订单，忘了删OrderItems，导致大量订单项变成孤儿，报表统计总金额虚高。

止血方案：

• 立即重建外键，设置ON DELETE CASCADE（仅限强依赖场景）或ON DELETE NO ACTION（推荐）；
• 编写数据修复脚本，找出所有OrderItems中OrderId不存在于Orders表的记录，标记为Orphaned；
• 在Application层OrderService.DeleteDraftAsync方法中，显式删除关联的OrderItems。

根本解法：外键是数据一致性的最后一道防线。我们在数据库设计评审会上，强制要求：

• 所有一对多关系，必须建外键；
• 外键名称统一格式：FK_{ChildTable}_{ParentTable}_{ParentColumn}；
• 在EF Core中，用HasForeignKey显式声明，确保迁移脚本能生成正确DDL。

5.5 坑：没做容量预估，单表亿级数据后无法维护

某导师指导的模拟项目X上线一年后，OrderItems表达1.2亿行，ALTER TABLE加字段耗时47分钟，期间服务不可用。DBA建议分表，但Application层代码全是context.OrderItems.Where(...)，改造成本巨大。

止血方案：

• 紧急启用SQL Server的在线索引重建（ALTER INDEX ... REBUILD WITH (ONLINE = ON)）；
• 将历史数据（1年前）归档到OrderItems_Archive表，主表只保留热数据；
• 在OrderItems表上添加PartitionKey AS YEAR(CreatedAt)计算列，并按年分区。

根本解法：在数据库设计之初，就做容量预估。我们建立《容量评估表》，针对每张核心表回答：

• 预估日增量：Orders表按日均5万单，OrderItems按平均每单3件 → 日增15万行；
• 预估留存周期：订单数据保留3年 → 总量约1.6亿行；
• 预估查询模式：90%查询按OrderId，10%按ProductId→ 主键聚簇索引建在OrderId，ProductId建非聚集索引；
• 预估维护窗口：ALTER TABLE操作必须在5分钟内完成 → 单表数据量上限5000万行，超限则分表。

这让我们在模拟项目X启动时，就决定OrderItems表按OrderId哈希分16个物理表，Application层通过ShardingKey路由，避免后期被动重构。

最后分享一个小技巧：在EF Core迁移中，用SqlServerDbContextOptionsBuilder配置MaxBatchSize，避免大数据量插入时超时：

optionsBuilder.UseSqlServer(connectionString, options => options.MaxBatchSize(1000)); // 每批1000条，降低锁持有时间

这种细节，往往决定了一次数据库发布的成败。