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

简介: 通过四色原型法进行领域建模,提取数据架构核心要素:红色时标原型(MI)表征业务流程节点,绿色参与方-物品原型(PPT)构建实体,黄色角色原型(Role)明确参与主体,蓝色描述原型(DESC)定义属性。基于风控系统流程,逐步构建领域模型,最终提炼出ER图,清晰展现实体间一对一、一对多、多对多关系,实现从业务到数据模型的精准转化。(238字)

领域模型图(数据架构/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 使用绿色表示)。
领域模型骨干图,如下:
3.领域模型角色
在领域模型骨干的基础上,需要把参与的角色(role)带进来。Role 使用黄色表示。如下图:
4.领域模型描述
最后将模型的描述信息添加进来,模型的描述信息中涵盖模型的具体属性。这些描述信息对于后面数据库设计有很大的影响。模型描述使用蓝色标注,如下图:
5.提取 ER 图
领域模型构建完成之后,在此基础上,我们已经能够初步的掌握整个系统的数据模型。其中绿色的 Part-Place-Thing Archetype(参与方-地点-物品原型),可以用来表示 ER 图中的实体模型。红色的 Moment-Interval Archetype(时标性原型),可以用来表示 ER 图中的关系。对领域模型架构图进行提炼,得到如下图:
实体(Entity)和联系(RelationShip)存在一定的关联关系,一般存在 3 种约束性关系: 一对一约束、一对多约束和多对多约束。将这些约束性关系表现在 ER 图中,用于展现实体与实体间具体的关联关系,最终输出 ER 图。(考虑保证 ER 的简洁性,这里并没有把模型的属性画进来)

相关文章
|
1天前
|
存储 编解码 JSON
16 RPC 实战:剖析 gRPC 源码,动手实现一个完整的 RPC
本课通过剖析gRPC源码,实战实现完整RPC框架。从动态代理、序列化到HTTP/2协议,详解请求发送与接收流程,涵盖Stub生成、数据封装、Frame传输、Netty编解码等核心机制,助你掌握高性能RPC设计精髓。
|
1天前
|
SQL 算法 关系型数据库
25熔断限流:业务如何实现自我保护?
本文探讨RPC框架下业务如何实现自我保护。服务端通过限流(如令牌桶、滑动窗口)防止过载,支持应用级、IP级控制,并可结合配置中心动态调整阈值;调用端则通过熔断机制避免因下游故障引发雪崩,可在动态代理层集成熔断器,提升系统稳定性。
|
1天前
|
运维 负载均衡 安全
23优雅关闭:如何避免服务停机带来的业务损失?
本文详解RPC中“优雅关闭”的重要性及实现方案。服务重启时,若未妥善处理,可能导致调用方请求失败。通过引入关闭钩子、设置请求挡板、主动通知调用方并结合引用计数等待在途请求完成,可实现无损下线。同时强调,仅依赖注册中心的服务发现无法保证实时性,需在服务端主动控制。最终确保关闭过程中新请求被拦截、旧请求被完成,保障业务连续性。
|
1天前
|
缓存 负载均衡 Java
24优雅启动:如何避免流量打到没有启动完成的节点?
优雅启动通过“启动预热”与“延迟暴露”机制,避免流量打到未就绪节点。启动预热让新实例逐步承接流量,利用JVM预热提升性能;延迟暴露则在应用完全启动后才注册服务,结合初始化Hook预加载资源,确保服务稳定。二者结合实现平滑上线,降低冷启动对业务的影响。
|
1天前
|
运维 监控 负载均衡
19健康检测:这个节点都挂了,为啥还要疯狂发请求?
本文深入探讨RPC框架中的健康检测机制,解析节点状态如何通过心跳与可用率动态判断。面对“半死不活”节点仍被调用的问题,提出结合业务请求成功率的优化方案,避免误判与雪崩。揭秘服务“亚健康”识别难点,并给出分布式环境下高可用检测设计实践,提升系统稳定性。
|
1天前
|
负载均衡 安全 数据库
22异常重试:在约定时间内安全可靠地重试
本文详解RPC框架中的异常重试机制:通过捕获网络异常并重试提升调用可靠性,需确保业务幂等、重置超时时间、排除故障节点,并支持可重试异常白名单配置,实现在约定时间内安全可靠的重试,避免超时失效与重复调用问题。
|
1天前
|
负载均衡 算法 网络协议
21负载均衡:节点负载差距这么大,为什么收到的流量还一样?
本文深入探讨RPC框架中的负载均衡机制,对比传统Web负载均衡的局限,提出自适应负载均衡方案。通过实时采集节点CPU、内存、响应耗时等指标,动态打分并调整权重,实现流量智能分配,有效避免因个别节点过载导致服务降级,提升系统整体稳定性与自动化治理能力。
|
1天前
|
存储 负载均衡 Dubbo
20 路由策略:怎么让请求按照设定的规则发到不同的节点上?
路由策略是RPC中实现流量控制的核心机制,通过设定规则将请求精准转发至指定节点。它支持灰度发布、IP过滤、参数路由等场景,实现流量隔离与平滑升级。相比服务发现层改造,动态配置路由规则更灵活高效,降低上线风险,提升系统可控性。(238字)
|
1天前
|
缓存 网络协议 关系型数据库
12丨核心原理:能否画张图解释下 RPC 的通信流程?
RPC(远程过程调用)是一种实现分布式系统间通信的核心技术,它让调用远程服务像调用本地方法一样简单。本文深入解析了RPC的定义、作用及通信流程:从序列化、网络传输、协议解析到动态代理等关键步骤,并揭示其在微服务架构中的“经络”地位。通过一张图讲清RPC全流程,帮助开发者理解底层原理,提升系统设计能力。
|
1天前
|
存储 缓存 负载均衡
18服务发现:到底是要 CP 还是 AP?
服务发现需权衡CP与AP。在超大规模集群中,强一致性(CP)如ZooKeeper易因高并发导致性能瓶颈,甚至雪崩。而最终一致性(AP)通过消息总线实现数据同步,具备更高可用性与扩展性,虽短暂延迟但可接受,更适配RPC场景。采用AP模式,结合推拉结合、增量更新与本地缓存,可保障系统稳定高效。