EditorialDiagram软件工程
Editorial ER 图设计工具 — 无阴影，告别 Mermaid 杂乱
用八个概念实体及明确的关系基数解释电商领域，把 Customer、Order、Line item 与 Product 的领域含义和 SQL 实现约束区分开。
导出图表
免费 PNG 包含 EditorialDiagram 角标。
排版规则与常见反模式
该图表的四条排版规则
- 01
实体盒分为命名的 ENTITY 头部与字段列表两部分；主身份以 # 标识，显示外部引用时用箭头前缀。
- 02
关系连接实体边界，在两端使用一致的基数记法：1、N、0..1 或 1..*。
- 03
相关实体靠近排列，大部分关系保持直线。非同轴关系使用正交通道，基数标签避开实体盒。
- 04
强调色用于聚合根。字段列表按实际内容决定高度，不为整齐补空行。
应避免的三种错误
- 把概念关系当成 SQL 外键删除行为，会混淆领域规则与存储约束。
- 混用不兼容的基数数字与乌鸦脚标记，会让关系两端含糊。
- 大模型逐一绘制所有外键，会形成连线纠缠而非有用的领域视图。
Engineer 与 Executive 密度对比
两种渲染基于同一个说明性示例。Executive 模式有意合并细节；在技术评审中使用总览前，请先阅读图注。
八个概念实体保留电商关系及源代码中的基数。
五个聚合层概念概括明细行、地址与产品分类。
何时应换用其他图表
关于该图表的常见问题
ER 图和数据库结构示例有何区别？
ER 示例连接概念实体盒并展示基数，例如一个 Order 包含一到多个 Line item。物理结构示例则打印 SQL 类型，并让每条外键连接具体列行，同时说明删除行为。应按评审问题选择视图。
Payment 或 Shipment 关系中的 0..1 表示什么？
表示本示例领域中，一个 Order 可以没有该关联实体，也可以有一个。这是建模假设，并非数据库唯一约束的证明。如果业务支持分次支付或多次发货，应先修改源代码中的基数。
Executive 模式为何没有 Line item、Address 与 Category？
五实体总览保留 Customer、Order、Products、Payment 与 Shipment 等聚合层概念，有意概括明细行、已存地址与产品分类。Engineer 模式保留全部八个源实体，适合领域模型评审。
示例使用说明性数据。编辑后的新布局需要 AI 服务；缓存预览可立即查看。
缓存示例可免费试用。Starter Pack 为 US$9.9 一次性购买；Pro Pass 为每月 US$8.9。每次生成固定消耗 10 积分，包含一次自动几何修正。 价格