领域模型图(数据架构/ER图)

简介: 数据架构核心产出是ER图,通过四色原型法进行领域建模:红色MI表时序事件,绿色PPT为业务实体,黄色Role示参与角色,蓝色DESC提供描述属性。以风控系统为例,从业务流程提炼MI,构建PPT实体,补充角色与描述,最终提取实体关系,形成ER图,指导数据模型设计。(239字)

数据架构重要的输出是数据-实体关系图,简称 ER 图。ER 图中包含了实体(数据对象)、关系和属性 3 种基本成分。ER 图可以用来建立数据模型。如何准确的建立产品的数据模型,需要分解出业务需要什么样的数据。数据域的分解过程是站在业务架构的基础上,对业务域进行模型分析的过程。说起业务建模,大家很快会想到领域模型这个概念。这里的思路是通过领域建模来逐步提取系统的数据架构图。
说到领域模型,这里采用四色原型法进行业务模型的抽象。在进行四色模型分析前,我们先了解下四色模型的一些基本概念。四色模型,顾名思义是通过四种不同颜色代表四种不同的原型。
Moment-Interval Archetype 时标性原型
表示事物在某个时刻或某一段时间内发生的。使用红色表示,简写为 MI.
Part-Place-Thing Archetype 参与方-地点-物品原型.
表示参与扮演不同角色的人或事物。使用绿色表示。简写为 PPT。
Role Archetype 角色原型
角色是一种参与方式,它由人或组织机构、地点或物品来承担。使用黄色表示。简写为 Role。
Description Archetype 描述原型
表示资料类型的资源,它可以被其它原型反复使用,并为其它原型提供行为。使用蓝色表示。简写为 DESC。
以风控系统为例,进行领域建模的过程如下:
1.关键流程
在进行业务建模前,首先需要梳理出业务的流程,这一步在业务架构分解环节中已经完成。按照四色建模法的原则,将业务流程图进行一点改造。在原来的流程图上,将流程涉及的事务和角色添加进来。
改造之后的流程图如下:
image.png

2.领域模型骨干
从业务流中,我们可以清晰的定义出 Moment-Interval Archetype (时标性原型),流程中的每个节点符合 MI 的定义,即事物在某个时间段内发生。在 MI 的定义过程中,一种方法是通过名词+动词进行定义。那么,风控的 MI 即为:数据采集、规则 &模型设置、风险识别、告警通知、风险处置、风险分析(MI 使用红色表示)。
在得到骨干之后,我们需要丰富这个模型,使它可以更好的描述业务概念。这里需要补充一些实体对象,通常实体对象包括:参与方、地点、物(party/place/thing)。
Part-Place-Thing Archetype(参与方-地点-物品原型):业务对象、规则、模型、异常风险、通知、异常事件、分析报告(PPT 使用绿色表示)。
领域模型骨干图,如下:
image.png

3.领域模型角色
在领域模型骨干的基础上,需要把参与的角色(role)带进来。Role 使用黄色表示。如下图:
image.png

4.领域模型描述
最后将模型的描述信息添加进来,模型的描述信息中涵盖模型的具体属性。这些描述信息对于后面数据库设计有很大的影响。模型描述使用蓝色标注,如下图:
image.png

5.提取 ER 图
领域模型构建完成之后,在此基础上,我们已经能够初步的掌握整个系统的数据模型。其中绿色的 Part-Place-Thing Archetype(参与方-地点-物品原型),可以用来表示 ER 图中的实体模型。红色的 Moment-Interval Archetype(时标性原型),可以用来表示 ER 图中的关系。对领域模型架构图进行提炼,得到如下图:
image.png

实体(Entity)和联系(RelationShip)存在一定的关联关系,一般存在 3 种约束性关系: 一对一约束、一对多约束和多对多约束。将这些约束性关系表现在 ER 图中,用于展现实体与实体间具体的关联关系,最终输出 ER 图。(考虑保证 ER 的简洁性,这里并没有把模型的属性画进来)
image.png

相关文章
|
2月前
|
监控 Java 测试技术
OOM排查之路:一次曲折的线上故障复盘
本文复盘了线上服务因Paimon与RocksDB集成引发的三次OOM故障。从线程激增到堆外内存泄漏,排查过程曲折复杂,最终定位到SDK中RocksDB通过JNI申请内存未释放的根本原因,并通过架构优化解决。分享了MAT、NMT、async-profiler等工具的实战经验,总结了一套系统性的内存问题排查思路,为类似技术栈提供借鉴。
|
2月前
|
存储 缓存 监控
EFC&CTO:缓存引发数据不一致问题排查与深度解析
EFC缓存架构更新后,在CTO测试中出现数据不一致问题。经排查,因分布式缓存版本号回退,导致旧NULL数据被读入pagecache并刷入文件系统,破坏了正常数据。通过维护递增版本号修复,10轮测试验证无误。
 EFC&CTO:缓存引发数据不一致问题排查与深度解析
|
2月前
|
安全 Java 测试技术
从Google线上故障,谈灰度发布的重要性
2025年6月12日,Google Cloud因未灰度发布的配置缺陷导致全球服务中断7小时。本文分析其根因为空指针异常,并详解Nacos等配置中心的灰度发布方案,强调通过IP、标签、流量等多路径实现安全配置变更,提升系统稳定性。
|
2月前
|
消息中间件 监控 Java
RocketMQ:底层Netty频繁OS OOM
本文记录了一例Java应用因Netty多ClassLoader加载导致堆外内存超限引发OS OOM的排查过程。通过NMT、Arthas等工具分析,发现多个中间件独立加载PooledByteBufAllocator,各自绕过MaxDirectMemorySize限制,累计占用远超1G堆外内存。最终定位RocketMQ客户端为主要内存使用者,建议短期调小Java堆以腾出空间,并推动中间件优化。
|
2月前
|
Java 关系型数据库 MySQL
[MES]数据库改造H2到MySQL(☆☆)
本文介绍如何运行并改造一个SpringBoot项目,包括从Gitee克隆代码、环境配置(JDK/Maven)、数据库由H2迁移至MySQL的步骤。强调新人如何高效请教同事、快速适应技术栈,掌握Git、Maven、MyBatis等核心技术,提升实战能力,助力入职后迅速进入角色。
 [MES]数据库改造H2到MySQL(☆☆)
|
2月前
|
自然语言处理 fastjson Java
|
2月前
|
存储 缓存 运维
一场FullGC故障排查
本文记录了一次线上JVM Full GC导致CPU使用率飙升至104%的问题排查与解决过程。通过分析发现,问题根源是将大Excel文件解析为List<Map>结构后长期驻留内存,造成堆内存膨胀,频繁Full GC。结合JProfiler工具定位大对象,最终提出“治本”与“治标”两类优化方案,并总结了JVM性能问题的排查思路与方法。
一场FullGC故障排查