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

简介: 本文介绍如何通过四色原型法构建领域模型,并逐步推导出数据架构中的ER图。采用红色(时标性)、绿色(参与方-物品-地点)、黄色(角色)和蓝色(描述)四色模型,结合风控系统案例,详解从业务流程到实体关系图的建模过程,助力精准梳理数据结构。

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

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

1.关键流程
在进行业务建模前,首先需要梳理出业务的流程,这一步在业务架构分解环节中已经完成。按照四色建模法的原则,将业务流程图进行一点改造。在原来的流程图上,将流程涉及的事务和角色添加进来。 改造之后的流程图如下:

管理人员

处理小二

风控小二

处理小二

风险事件

数据对象

规则/模型

异常风险

通知

分析报告

规则&模型

风险处置

告警通知

数据采集

风险分析

风险识别

设置


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

PARTPLACETHING

PARTPLACETHING

PARTPLACETHING

通知

异常风险

业务对象

MI

MI

MI

MI

数据采集

风险识别

规则&模型

风险告警

设置

PARTPLACETHING

PARTPLACETHING

MI

MI

规则

模型

风险处置

风险分析

PARTPLACETHING

PARTPLACETHING

异常事件

分析报告


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

PARTPLACETHING

PARTPLACETHING

PARTPLACETHING

通知

异常风险

业务对象

ROLE

处理小二

MI

MI

MI

MI

规则&模型

数据采集

风险识别

风险告警

设置

ROLE

风控小二

MI

MI

风险分析

风险处置

ROLE

ROLE

PARTPLACETHING

PARTPLACETHING

管理人员

处理小二

规则

模型

PARTPLACE THING

PARTPLACETHING

分析报告

异常事件


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

DESCRIPTION

DESCRIPTION

风险描述

通知内容

PARTPLACETHING

PARTPLACETHING

PARTPLACETHING

异常风险

通知

业务对象

ROLE

处理小二

MI

MI

MI

MI

风险告警

数据采集

规则&模型

风险识别

设置

ROLE

风控小二

MI

MI

风险分析

风险处置

ROLE

ROLE

PARTPLACETHING

PARTPLACETHING

管理人员

处理小二

模型

规则

PARTPLACETHING

PARTPLACETHING

异常事件

分析报告

DESCRIPTION

DESCRIPTION

DESCRIPTION

规则描述

模型描述

DESCRIPTION

报告详情

事件详情


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

模型类型

属于

通知

风险报告

模型

告警

分析

处置人

风险事件

处理

识别

规则

属于

规则类型


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

模型类型

属于

通知

风险报告

U

1

模型

分析

告警

风险事件

处置人

处理

识别

M

U

规则

属于

规则类型


2 人点赞

2


相关文章
|
Shell Linux 数据安全/隐私保护
Linux Shell入门:掌握基本命令和脚本编写
Linux Shell是Linux操作系统中的命令解释器,允许用户通过命令行界面与操作系统进行交互。掌握Shell基础是成为Linux系统管理员或开发人员的关键。本文将介绍Linux Shell的基本知识,包括常用命令和简单脚本编写。
422 0
|
2月前
|
安全 Java 应用服务中间件
4.认识SpringSecurity
Spring Security 是 Spring 生态中的安全框架,提供认证、授权及安全防护功能。支持多种认证方式(如表单、OAuth2、JWT等),基于过滤器链实现请求控制,可防御 CSRF 等攻击,保障 Web 应用安全。
|
4月前
|
人工智能 数据安全/隐私保护
如何识别AI生成内容?探秘“AI指纹”检测技术
如何识别AI生成内容?探秘“AI指纹”检测技术
624 119
Guava - Maps.difference
Guava - Maps.difference
931 0
|
6月前
|
敏捷开发 开发框架 测试技术
从零开始:如何快速开发一个软件?实用方法 + 避坑指南
本文介绍了如何在保证质量的前提下快速开发软件,涵盖从需求分析到上线推广的完整流程。内容包括敏捷开发、MVP设计、工具选择、团队协作与持续运营等关键环节,适合初创团队、企业试点及个人开发者参考,帮助高效验证产品价值,缩短开发周期,降低试错成本。
|
3月前
|
开发框架 Java 测试技术
领域驱动设计(DDD)在中小型项目中的落地实践
本文探讨领域驱动设计(DDD)在中小型项目中的落地实践,涵盖核心概念如领域模型、聚合、限界上下文与事件驱动架构,并结合电商订单系统案例,展示分层架构、仓储模式与领域服务的实际应用,助力团队构建高内聚、易维护的业务系统。
711 10
|
5月前
|
存储 测试技术 C#
DDD领域驱动设计:实践中的聚合
领域驱动设计(DDD)中的聚合根是管理复杂业务逻辑和数据一致性的核心概念。本文通过任务管理系统示例,讲解如何设计聚合根、处理多对多关系、强制业务规则及优化性能,帮助开发者构建结构清晰、可维护的领域模型。
628 12
DDD领域驱动设计:实践中的聚合
|
Rust 前端开发 jenkins
Tauri 开发实践 — 使用 CI/CD 自动构建发布 Tauri 桌面端应用
本文介绍如何使用 CI/CD 自动构建发布 Tauri 应用。Tauri 是一个轻量级跨平台客户端框架,适合个人应用。文章首先概述了 CI/CD 的基本流程,并介绍了 GitHub Actions、GitLab CI 和 Jenkins 三种工具。最终选择了 GitHub Actions 进行配置。文中详细展示了使用 GitHub Actions 脚本实现 Tauri 应用构建的过程,并解决了权限和安全问题。项目源码可在 GitHub 上获取。
1055 5
Tauri 开发实践 — 使用 CI/CD 自动构建发布 Tauri 桌面端应用
|
11月前
|
人工智能 前端开发 Java
DDD四层架构和MVC三层架构的个人理解和学习笔记
领域驱动设计(DDD)是一种以业务为核心的设计方法,与传统MVC架构不同,DDD将业务逻辑拆分为应用层和领域层,更关注业务领域而非数据库设计。其四层架构包括:Interface(接口层)、Application(应用层)、Domain(领域层)和Infrastructure(基础层)。各层职责分明,避免跨层调用,确保业务逻辑清晰。代码实现中,通过DTO、Entity、DO等对象的转换,结合ProtoBuf协议,完成请求与响应的处理流程。为提高复用性,实际项目中可增加Common层存放公共依赖。DDD强调从业务出发设计软件,适应复杂业务场景,是微服务架构的重要设计思想。
|
消息中间件 JSON Java
Spring Boot、Spring Cloud与Spring Cloud Alibaba版本对应关系
Spring Boot、Spring Cloud与Spring Cloud Alibaba版本对应关系
32616 0