DDD的优势(4)

简介: DDD的优势(4)

7.6.2 四色建模法

1.方法介绍

四色建模法源于Peter Coad的Java Modeling In Color With UML一书,它是一种模型的分析和设计方法,要把所有模型分为4种类型,用4种颜色表示,如图7-15所示。


image.png


在四色模型中,我们将抽象出来的对象分成4种原型(archetype)。


(1)业务关键时刻(Moment-Interval)

这种对象表示那些在某个时间点存在或者会存在一段时间。这样的对象往往表示了一次外界的请求,比如一次询价(Quotation)、一次下单(Order)或者一次租赁(Rental)。


Moment-Interval是最重要的一类对象,是系统的价值所在,一般用粉红色来表示。这样的对象一般有一个起始时间和终止时间,以及一个唯一的标识号,用来唯一地标识这一次客户请求,比如OrderNo。


注意,“业务关键时刻”是我给“Moment-Interval”起的中文名称,本来想直译为“时刻-时间段”,但感觉“时刻-时间段”不能体现出这种对象类型的重要性。


(2)角色(Role)


这种对象表示一种角色,往往由人或者物来承担,会有相应的责任和权利。一般,一个Moment-interval对象会关联多个Role。例如,一次下单涉及两个Role,分别是客户(Customer)和商品(Product)。


这类对象是除Moment-interval对象之外最重要的一类对象,一般用黄色来表示。


(3)人-事-物(Party,Place or Thing)


这种对象往往表示一种客观存在的事物,例如人、组织、产品或者配件等,这些事物会在一种moment-interval 中扮演某个Role。例如,某个人既会在一次购买中扮演Customer的角色,也可以在询价中扮演询价人的角色。这类对象的重要程度排在第三,一般用绿色来表示。


(4)描述(Description)


这种对象一般是用于分类或者描述性的对象,它的属性一般是这一类事物都有的属性,一般用蓝色来表示。


2.案例介绍


下面通过一个电商业务场景,来介绍如何通过四色模型进行建模,该案例来自InfoQ的文章《运用四色建模法进行领域分析》。


用户故事如下:


现在你是一家在线电子书店的COO。突然有一天,有一位顾客向你投诉,说他订购的书少了一本,并且价钱算错了,他多给了钱。在承诺理赔之前,你需要核对这位顾客说的是否属实。那么这时你需要知道什么样的信息才能做出准确的判断。

简单来说,你需要知道这位顾客订购了哪些书籍、付了多少钱,以及书店到底为这个顾客递送了哪些书籍。不幸的是,由于科技不够发达,你无法直接驾驶时间机器回到从前去亲眼看看发生了什么事。但幸运的是,你并不需要这么做,你只需要看看这位顾客的订单和网银的支付记录,以及你们书店交给EMS的快递单存根,就可以知道这些信息了。


从上面这个故事中我们可以看到:任何的业务事件都会以某种数据的形式留下足迹。我们对于事件的追溯可以通过对数据的追溯来完成。正如在故事中,你无法回到从前去看看到底发生了什么,但是却可以在单据的基础上,一定程度地还原当时事情发生的场景。当把这些数据的足迹按照时间顺序排列起来,我们几乎可以清晰地推测出在过往的一段时间内发生了哪些事情。


为什么这些业务数据具备可追溯性(Tracibility)呢?因为这些数据都是关键业务流程执行的结果。如图7-16所示,比如订单是业务的起点,而快递存根是业务的终点,正是这些数据在支撑运营体系的关键流程的执行结果。


image.png


除了上述例子之外,对于任何一笔正常的经济往来,我们需要知道如下内容。


  • 如果我付出一笔资金,那么我的权益是什么?
  • 如果我收到一笔资金,那么我的义务是什么?


这些问题都需要业务系统捕捉到相应的足迹才能够回答,所以企业的业务系统的主要目的之一,就是记录这些足迹,并将这些足迹形成一条有效的追溯链。


足迹通常都具有一个有意思的特性,即它们是Moment-interval(要么是“时间时刻”,要么是“时间段”)的。发现这些业务关键时刻对象就是建模的起点。对这些对象稍加整理,我们就能得到图7-17所示的整个领域模型的骨干。




相关文章
|
2月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
5月前
|
缓存 前端开发 安全
DDD中的分层架构
领域驱动设计(DDD)的分层架构演进为依赖倒置的四层模型,强调关注点分离。表现层(UI)展示信息并处理用户指令,应用程序层负责用例编排,与领域层交互但不含业务逻辑。领域层承载核心业务逻辑,包含领域模型和服务,确保业务正确性。基础设施层提供技术支撑,如数据库和缓存,服务于其他层。各层解耦,实现灵活的系统架构。
101 0
|
7月前
|
数据库
DDD架构浅谈
DDD架构浅谈
152 4
|
消息中间件 JavaScript 小程序
领域驱动设计(DDD)的几种典型架构介绍
领域驱动设计(DDD)的几种典型架构介绍
|
敏捷开发 架构师 领域建模
别吵,可落地的DDD!
别吵,可落地的DDD!
492 0
|
消息中间件 架构师 Dubbo
DDD的基础设施到底在哪里
DDD的基础设施到底在哪里
DDD的基础设施到底在哪里
|
设计模式 缓存 Java
DDD之代码架构
这是一篇迟到的文章。这其实是我写DDD的第四篇文章。去年11月份左右我在个人网站上写了三篇关于DDD的文章,都是比较偏战略部分的。那个时候我还在一个正在使用DDD的项目上,也是我第一次真正开始深入使用DDD。
620 1
|
设计模式 JSON 缓存
|
设计模式 领域建模 数据库
DDD领域驱动设计落地实践系列:初识DDD
笔者在经历的很多项目中都使用了DDD领域驱动设计进行架构设计,尤其是在业务梳理、中台规划以及微服务划分等方面,DDD是重要的架构设计方法论,对平时的架构设计有非常好的指导作用。从本文开始笔者将通过一系列的文章阐述自己对于DDD的理解以及如何在项目实战中落地实践DDD。本文作为系列文章的开端,主要和大家聊聊DDD的一些基本概念以及常用方法。
DDD领域驱动设计落地实践系列:初识DDD
|
自然语言处理 测试技术 领域建模
DDD的优势(3)
DDD的优势(3)
276 0
DDD的优势(3)