DB-数据库设计-进销存系统（一）

要设计一套 “业务域隔离且互联互通” 的商超进销存系统，核心是通过领域驱动设计（DDD）划分边界，结合事件驱动架构解耦交互，最终实现 “实时利润可视化”。整体设计需兼顾 “域独立性”（便于单独迭代）和 “数据关联性”（支撑利润计算），具体方案如下：

一、业务域划分：明确边界与核心职责

基于传统商超业务流程，划分为 6 个核心业务域（含 2 个基础支撑域），每个域独立负责特定业务，但通过 “标准化接口” 和 “领域事件” 协同工作。

业务域	核心职责	核心实体（数据）	对外交互场景
商品域（基础域）	管理商品全生命周期基础信息（唯一数据源）	商品（ID、名称、类别、规格、单位、默认售价、计税方式等）、商品分类	向采购 / 销售 / 仓储域提供商品基础信息；接收 “商品新增 / 变更” 事件同步至其他域
组织域（基础域）	管理商超组织架构（仓库、门店、部门等）	仓库（ID、位置、负责人）、门店（ID、地址、类型）、部门（采购部、财务部等）	向所有域提供组织基础信息；支持按组织维度（如 “某门店”“某仓库”）隔离数据
采购域	供应商管理、采购计划、采购订单、进货验收	供应商（ID、名称、结算方式）、采购订单（单号、商品、数量、采购单价、到货仓库）、验收单	向仓储域推送 “进货验收完成” 事件（触发库存增加）；向财务域推送 “采购应付” 事件
仓储域	库存管理（入库 / 出库 / 调拨）、库位管理、盘点、库存成本核算	库存台账（商品 ID、仓库 ID、数量、成本单价、总成本）、调拨单、盘点单	接收采购域 “进货” 事件增加库存；接收销售域 “出货” 事件减少库存；向财务域推送 “库存成本变动” 事件
销售域	门店销售、促销活动、销售订单、退换货	销售单（单号、门店、商品、数量、销售单价、折扣）、促销规则、退换货单	向仓储域推送 “销售出货” 事件（触发库存减少）；向财务域推送 “销售收入” 事件
财务域	收支核算、成本归集、利润计算、对账	应付账款（关联采购单）、应收账款（关联销售单）、利润台账（实时更新）、对账记录	接收采购 / 销售 / 仓储域事件计算成本与收入；提供 “实时利润查询” 接口

二、域间交互设计：事件驱动 + 接口服务（解耦核心）

各域通过 “领域事件异步通信”（解决跨域数据同步）和 “标准化接口同步查询”（解决实时数据依赖）协同，避免直接耦合。

1. 领域事件：跨域数据同步的核心（异步）

通过消息队列（如 RabbitMQ）传递事件，确保 “一个域的业务动作” 自动触发 “其他域的联动动作”，且不阻塞原业务流程。

触发场景	领域事件	订阅域	订阅域动作
采购验收完成	【采购。验收完成】	仓储域、财务域	仓储域：按验收单增加对应仓库的商品库存（更新库存台账）；财务域：记录应付账款（基于采购单价）
销售单生成	【销售。订单完成】	仓储域、财务域	仓储域：按销售单减少对应门店 / 仓库的商品库存；财务域：记录销售收入（基于销售单价）
销售退货完成	【销售。退货完成】	仓储域、财务域	仓储域：增加库存；财务域：冲减销售收入，调整成本
库存成本变动	【仓储。成本更新】	财务域	财务域：更新商品单位成本（用于后续利润计算）
商品信息变更	【商品。信息更新】（如售价调整）	销售域、采购域	销售域：同步更新默认售价；采购域：若涉及规格变更，同步调整采购单模板

2. 标准化接口：实时数据查询（同步）

各域暴露只读接口，供其他域查询 “不常变更的基础数据” 或 “实时状态”，避免数据冗余存储。

接口提供方	核心接口示例	调用场景
商品域	GET /api/products/{id}（查询商品信息）	采购域创建采购单时校验商品是否存在；销售域收银时获取商品默认售价
组织域	GET /api/warehouses/{id}（查询仓库信息）	采购域指定到货仓库时校验仓库有效性；仓储域调拨时校验目标仓库是否存在
仓储域	GET /api/inventory/{productId}/{warehouseId}（查询实时库存）	销售域收银时校验商品库存是否充足；采购域制定采购计划时参考当前库存
财务域	GET /api/profit?dim=store&date=2024-10-21（查询实时利润）	前端仪表盘展示 “某门店当日利润”；管理层查看全司实时利润

三、核心流程示例：从 “采购” 到 “销售” 的全链路协同

以 “商品 A 从采购到销售，最终实时计算利润” 为例，说明域间交互：

1. 采购流程：
   • 采购域创建采购单（商品 A，数量 100，采购单价 8 元，到货仓库 W1），经审批后向供应商下单；
   • 商品到货后，采购域生成验收单（确认实收 100 件），发布【采购。验收完成】事件（含商品 A、数量 100、单价 8 元、仓库 W1）；
   • 仓储域订阅事件：更新库存台账（商品 A 在 W1 的库存 = 原库存 + 100，成本单价 = 8 元，总成本 = 800 元），并发布【仓储。成本更新】事件（商品 A 成本 8 元）；
   • 财务域订阅事件：记录应付账款（供应商 XXX，金额 800 元）。
2. 销售流程：
   • 门店 S1 销售商品 A（数量 10，销售单价 15 元），销售域生成销售单，发布【销售。订单完成】事件（商品 A、数量 10、售价 15 元、门店 S1）；
   • 仓储域订阅事件：减少仓库 W1（假设门店 S1 从 W1 补货）的商品 A 库存（100→90）；
   • 财务域订阅事件：
     • 计算收入：10×15=150 元（计入门店 S1 当日收入）；
     • 调用仓储域接口获取商品 A 的成本单价（8 元），计算成本：10×8=80 元；
     • 实时更新利润台账：门店 S1 当日利润 = 收入 - 成本 = 150-80=70 元（累计）。
3. 实时利润查询：
   • 管理层通过前端查询 “门店 S1 当日利润”，前端调用财务域GET /api/profit?dim=store&id=S1&date=今日接口；
   • 财务域从利润台账中提取数据返回（实时更新，延迟 < 1 分钟）。

四、数据模型设计：域内独立 + 关联唯一

各域数据库独立（避免共享数据库导致耦合），通过 “全局唯一标识”（如商品 ID、订单号）关联跨域数据。

域	核心表设计（简化）	核心索引
商品域	products（id, name, category_id, spec, unit, default_price, tax_type, ...）	PRIMARY KEY (id)
组织域	warehouses（id, name, location, ...）；stores（id, name, address, ...）	PRIMARY KEY (id)
采购域	purchase_orders（id, supplier_id, warehouse_id, status, ...）；purchase_items（order_id, product_id, quantity, purchase_price, ...）	KEY (warehouse_id)；KEY (product_id)
仓储域	inventory（product_id, warehouse_id, quantity, cost_price, total_cost, ...）	UNIQUE KEY (product_id, warehouse_id)
销售域	sales_orders（id, store_id, status, ...）；sales_items（order_id, product_id, quantity, sale_price, ...）	KEY (store_id)；KEY (product_id)
财务域	profit_ledger（dim_type, dim_id, date, total_income, total_cost, profit, ...）（dim_type：store/warehouse/product）	KEY (dim_type, dim_id, date)

五、技术架构：微服务 + 事件驱动（支撑高可用）

采用 “微服务架构” 承载各业务域，通过 “事件总线” 和 “API 网关” 实现交互，确保系统可扩展、易维护。

1. 服务拆分：每个业务域对应一个微服务（如product-service、purchase-service），独立部署、独立迭代；
2. 通信层：
   • 同步通信：通过 Spring Cloud OpenFeign 调用跨域接口，API 网关（如 Spring Cloud Gateway）统一入口；
   • 异步通信：通过 Kafka/RabbitMQ 实现事件发布订阅，确保跨域数据最终一致；
3. 数据存储：各服务使用独立数据库（MySQL/PostgreSQL），财务域可引入 Redis 缓存实时利润指标，提升查询性能；
4. 监控与追溯：通过链路追踪（如 SkyWalking）监控跨域流程，事件日志（ELK）记录所有领域事件，便于问题排查。

六、核心优势：兼顾 “隔离性” 与 “协同性”

1. 业务域解耦：各域可独立开发、测试、上线（如采购域优化验收流程，不影响销售域），降低维护成本；
2. 实时利润可视化：通过事件驱动实时同步收入、成本数据，财务域动态计算利润，支持 “商品 / 门店 / 时间段” 多维度查询；
3. 可扩展性强：新增业务（如 “线上商城销售”）只需新增 “线上销售子域”，通过事件接入现有体系，无需重构核心系统；
4. 数据一致性：基于领域事件的最终一致性方案，结合重试机制（如死信队列），确保跨域数据不丢失、不重复。

总结

这套系统通过 “领域划分明确边界、事件驱动解耦交互、微服务支撑独立迭代”，既保留了传统进销存各环节的专业性，又实现了数据的实时联动，最终支撑 “随时查看利润” 的核心目标。关键是在 “隔离” 与 “协同” 之间找到平衡 —— 域内高度自治，域间通过标准化事件和接口轻量交互，避免陷入 “糅杂在一起” 的混乱。