痛点一：复杂系统的设计和逻辑碎片化散落，缺少沉淀导致系统后期维护、迭代以及架构升级都非常困难。
痛点二：由于新需求或新项目导致的系统的老旧逻辑梳理往往耗费大量人力，甚至造成人才的流失。
痛点三：多团队共建场景下需要参与各方了解跨应用系统的整体设计，沟通效率低成本高、共建初期花费时间长。
痛点 N：像这样的痛点还有很多...
如何解？怎么破？我们从 ERD 中寻找答案。
ERD 是源自于硅谷的工程技术实践，其核心价值沉淀应用系统全生命周期的技术资产，理解应用系统整体设计演进过程，促进技术与业务理解，降低共建成本。
•ERD 在项目低成本时期介入，把风险和成本控制到最低。
•ERD 能规范描述，减少沟通，促进协作，提升效率。
•ERD 有助于合理拆解大型项目形成更小的任务更容易进行分配。
•可对照 PRD 反向检查 ERD，确保设计意图，实现产品目标。
•ERD 能清楚的描述落地范围以及上下游依赖和可能的风险。
在介绍 ERD 时肯定有朋友对 TRD 有所了解，在这里用一张表格直观了解它们的区别：
| ERD | TRD | |
|---|---|---|
| 受众 | 业务、产品、研发 | 研发 |
| 描述对象 | 系统 | 需求 |
| 目标 | 资产沉淀 | 技术实现 |
| 时效性 | 持续迭代 | 一次性 |
| 更新时机 | 按需 | 实时 |
ERD 核心着眼于系统视角，实现系统级的技术资产沉淀，TRD 偏向于需求开发，通过架构设计细节描述指导实际开发工作，两者相辅相成，优势互补。
在规范制定初期我们结合技术中心系统的现状、猎豹项目，联合技术中心各部门架构师共同制定并评审了零售 ERD 编写规范，规范依照奥卡姆剃刀提供最小必要内容及可选内容：
零售 ERD 规范模版链接：
注：由于前后端的系统差异性，特别制定了前端版。
目前 ERD 在整个中心的推广与影响力的打造由全渠道首先侧落地执行并处于领跑角色，整体从 2022 年底启动，现阶段处于部门全面推广落地阶段。
从开始至今一年多以来，我们以**定规范**、**推落地**、**看质量**、**选标杆**、**推影响**、**沉资产**的实际行动贯穿着整个时间线。
全渠道全年 0-2 级别应用对应的系统 ERD 全覆盖共计**259**个，ERD 季度评优共计 26 个优秀 ERD 。
2023 年上旬在技术中心范围推广 ERD 规范和标杆案例并推动试点，组织并评审通过 5 个 C2 部门共 6 个 ERD。
•利用 AIGC 能力，结合当前业务可视化，生成部分 ERD 内容，例如：在接口及名词解释等内容上进行自动化更新。
•分级简化，针对 L3 级应用（边缘或长期不维护，但无法下线）进行 ERD 简化模板，减少研发维护成本。
•在技术中心范围内扩大推广。
1.书写内容完整，要求的核心要素描述完整。
2.设计图采用标准 UML，使用 UML 插入的方式方便后续迭代更新，原图可编辑。
3.核心要素设计满足业务场景且具有扩展性。
•架构设计合理清晰，要求使用 C4 中的 C2 容器图，画图工具建议使用 draw.io。
•架构设计图和部署图要写实反映系统真实情况例如部署上是否涉及一套代码多套部署（商业化/主站）；
•上下游依赖和边界清晰；
•系统内的应用/组件设计合理，高内聚低耦合；
•核心组件在详设中交互序列图清晰，依赖关系合理；
•业务建模，子域、领域服务、能力和扩展点、领域对象、业务身份设计合理（适用于采用 BPaaS 架构应用）；
•涵盖对外的接口定义，且描述清晰，出入参没有二义性；
•缓存设计优先考虑采用主动缓存，是否存在溢出风险；是否存在大 KEY；缓存时效是否合理等；
•数据库 ER 图、索引合理有效；
•风险预案必须说明是有损/无损降级和其业务影响；
•风险预案描述操作步骤清晰，可按步骤执行；
•部署上要有多机房容灾，涉及 C 端下单和生产链路上系统可跨机房切换；
•0 级应用必须有大促容量、SLO 评估。
最后，欢迎一起交流～
作者：京东零售 魏星
来源：京东云开发者社区 转载请注明来源
