架构设计实践五部曲(三):从领域模型提取数据架构

发布于:2019 年 9 月 26 日 20:53

前阿里 P9 技术专家 李运华,正在传授十几年架构实战心法,超过 46000 人跟随学习,点击查看 >>
架构设计实践五部曲(三):从领域模型提取数据架构

数据架构重要的输出是数据 - 实体关系图,简称 ER 图。ER 图中包含了实体(数据对象)、关系和属性 3 种基本成分。ER 图可以用来建立数据模型。如何准确的建立产品的数据模型,需要分解出业务需要什么样的数据。数据域的分解过程是站在业务架构的基础上,对业务域进行模型分析的过程。说起业务建模,大家很快会想到领域模型这个概念。这里的思路是通过领域建模来逐步提取系统的数据架构图。

说到领域模型,这里采用四色原型法进行业务模型的抽象。在进行四色模型分析前,我们先了解下四色模型的一些基本概念。

四色模型,顾名思义是通过四种不同颜色代表四种不同的原型。

  1. Moment-Interval Archetype 时标性原型

表示事物在某个时刻或某一段时间内发生的。使用红色表示,简写为 MI.

  1. Part-Place-Thing Archetype 参与方 - 地点 - 物品原型.

表示参与扮演不同角色的人或事物。使用绿色表示。简写为 PPT。

  1. Role Archetype 角色原型

角色是一种参与方式,它由人或组织机构、地点或物品来承担。使用黄色表示。简写为 Role。

  1. Description Archetype 描述原型

表示资料类型的资源,它可以被其它原型反复使用,并为其它原型提供行为。使用蓝色表示。简写为 DESC。

还是以风控系统为例,进行领域建模的过程如下:

1. 关键流程

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

改造之后的流程图如下:

架构设计实践五部曲(三):从领域模型提取数据架构

图 1

2. 领域模型骨干

从业务流中,我们可以清晰的定义出 Moment-Interval Archetype (时标性原型),流程中的每个节点符合 MI 的定义,即事物在某个时间段内发生。在 MI 的定义过程中,一种方法是通过名词 + 动词进行定义。那么,风控的 MI 即为:数据采集、规则 & 模型设置、风险识别、告警通知、风险处置、风险分析(MI 使用红色表示)。

在得到骨干之后,我们需要丰富这个模型,使它可以更好的描述业务概念。这里需要补充一些实体对象,通常实体对象包括:参与方、地点、物(party/place/thing)。

Part-Place-Thing Archetype(参与方 - 地点 - 物品原型):业务对象、规则、模型、异常风险、通知、异常事件、分析报告(PPT 使用绿色表示)。

领域模型骨干图,如下:

架构设计实践五部曲(三):从领域模型提取数据架构

图 2

3. 领域模型角色

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

架构设计实践五部曲(三):从领域模型提取数据架构

图 3

4. 领域模型描述

最后将模型的描述信息添加进来,模型的描述信息中涵盖模型的具体属性。这些描述信息对于后面数据库设计有很大的影响。

模型描述使用蓝色标注,如下图:

架构设计实践五部曲(三):从领域模型提取数据架构

图 4

5. 提取 ER 图

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

架构设计实践五部曲(三):从领域模型提取数据架构

图 5

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

架构设计实践五部曲(三):从领域模型提取数据架构

图 6

最终一种好的 ER 图需要具备以下原则:

  • 同一实体在同一个 ER 图中只能出现一次

  • 先设计局部 ER 图,再把每一个局部 ER 图综合起来,生成总体的 ER 图。

作者简介

胡斌,菜鸟网络技术专家,目前负责菜鸟风控系统的建设。曾在淘宝技术部先后负责卖家平台、商家运营等领域。在大规模分布式应用、大数据、架构领域有多年的开发和管理经验。

延展阅读

架构设计实践五部曲(一):架构与架构图

架构设计实践五部曲(二):业务架构与产品架构设计实践

阅读数:5006 发布于:2019 年 9 月 26 日 20:53

更多 架构、大数据、方法论 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 商品列表页:创建商品表、品牌表

    2020 年 8 月 27 日

  • Flow Model 的架构与设计

    通过前面文章的介绍,相信大家对TLF的基本架构已经有所了解。本文将着重介绍TLF里的核心内容——Flow Model,包括Flow Model的组织结构和TLF的Format。

    2011 年 9 月 9 日

  • 微服务架构模型:几种常见模型的对比和分析

    这些架构模型在我们的实际应用中都具有很高的借鉴价值。

    2019 年 10 月 30 日

  • MVC 架构解析:模型(Model)篇

    模型就是当我们使用软件去解决真实世界中各种实际问题的时候,对那些我们关心的实际事物的抽象和简化。

    2019 年 9 月 27 日

  • 领域驱动设计(DDD)在有赞教育线索资源管理的实践

    本文介绍领域驱动设计在有赞教育线索资源管理的实践。

    2019 年 9 月 10 日

  • DDD 实践:如何用 DDD 重构中台业务模型?

    这一讲会用一个传统企业中台建模的案例,带你一起用DDD的设计思想来构建中台业务模型。

    2019 年 11 月 8 日

  • 中台之上(六):如何为一个商业银行设计业务架构?

    从实际操作的角度讲,企业级业务架构设计及其建模过程是一个充满可能性和争议的过程,并没有一个直观的量化标准能够用于判断一个架构方案的好坏,我们可以通过一个虚拟的例子体会一下。

    2019 年 3 月 4 日

  • 用故事图为用户故事提供上下文

    Scrum中“backlog”指的是一个单独的经过优先级排序的故事列表,由团队进行实现。这个东西在组织管理团队近期工作目标的时候很有用,例如Scrum计划会议。Jeff Patton在Orlando Scrum Gathering大会上描述了故事图的概念。这个方法可以给故事提供更丰富的上下文,有助于制定发布计划。

    2009 年 3 月 30 日

  • Greg Young 谈使用文档和流程代替事件

    并非所有系统都是基于事件或事实的。在某些问题域里,使用事件非常贴切,它们表示在各个时间点发生的事实。“但是,也有很多系统却关注流程中的信息流动”,Greg Young近日在伦敦举办的DDD Exchange Day大会上如是说,他以一个银行抵押贷款的应用作为示例来说明他的观点。

    2013 年 7 月 7 日

  • 文章:业务过程执行的 7 个谬误

    在这篇新的InfoQ文章中,Jean-Jacques Dubray探讨了服务于BPMS的一个新的架构蓝图,它更清晰的调整了SOA和BPM之间的关系。Jean-Jacques声称:经过8年多的认真研究之后,我们远没有能力使用业务分析师设计出的业务过程模型来创建完全可行的解决方案。

    2008 年 1 月 28 日