DDD中领域故事的作用

本文涉及的产品
视觉智能开放平台,分割抠图1万点
NLP 自学习平台,3个模型定制额度 1个月
NLP自然语言处理_高级版,每接口累计50万次
简介: 【8月更文挑战第14天】

0 前言

开始一个新项目时,只是依赖于一份需求列表指导工作。基本上,你只能依靠几句试图解释系统预期功能和限制的句子来开展工作。对将要解决的问题或项目要缓解的用户痛点毫无了解。

1 没有DDD时的问题解决

这些项目导致与产品部门来回讨论,以真正理解所需的行为并了解可能的边界情况,结果是无效的会议和浪费时间。

这正是DDD进入软件世界要解决的问题。DDD 是一套用于有效处理问题并高效地通过业务软件解决问题的技术。

在这篇文章中,我不会向你解释什么是DDD,因为我假设如果你正在阅读这篇文章,那么你已经有了一些背景知识。有了DDD,最初描述的场景看起来完全不同。DDD的目标是让所有领域专家使用相同语言(统一语言,Ubiquitous Language)并共享对问题的相同理解。这样,你作为开发人员可以直接与其他利益相关者、产品经理、业务分析师等进行沟通,使用一种共同的方式进行交流。

2 使用DDD时的问题解决

共享模型,即领域模型(Domain Model),基本上是公司不同领域专家之间共享的知识。该模型包括用户的痛点、所有人的共享语言以及对用户感受和需要解决的问题的理解。

这种技术上称为“统一语言(Ubiquitous Language)”的共享语言是通过所有利益相关者一起开会讨论术语和不同观点来实现的,它将成为你领域建模的基础。

3 UL 的定义

在团队共享了共同的语言之后,领域故事讲述(Domain Storytelling)就开始发挥作用了。领域故事讲述是一种将领域知识转化为业务软件的协作技术。它是一种将各利益相关者的知识转化为实体、关系、上下文等,最终转化为代码的方式。

4 入门指南

让我们开始解释如何在你公司面临的任何问题中实施领域故事讲述。

第一步当然是将所有利益相关者聚集在一个房间或在线会议中,开始一起绘制和草拟图表。一旦大家都在同一个房间里,你应该开始分享你对问题的看法和知识,以便其他人可以更多地了解它。

之后,就开始绘图了。但不是任何形式的绘图,我们不想开始绘制受到数据库关系或编程语言影响的技术图表。我们,开发人员,已经有一种绘制图表的语言。UML是一个很棒的建模语言,别误会,但你不希望产品部门的人因为你那些花哨的技术图表而感到无聊。你需要使用一种对所有人更易理解的东西,从业务分析师到产品经理。你要用“讲故事”的方式绘制这些“蓝图”。没错,你希望通过讲故事来表达一个流程(如用户去超市拿了一袋土豆,然后去收银员那里付款)。

这些故事是基于我将向你展示如何绘制的图表创建的。这些图表使用了一组特定的符号,这些符号共同构成了所谓的“象形语言(Pictographic Language)”。这种语言由四个元素组成:

  • 一个“参与者”actor
  • 一个“工作对象”work object
  • 一个“动作”action
  • 一个“序列号”sequence number

如“客户签署合同”可表示为:

基本元素

在象形语言中有一些指南。其中之一是,参与者从不重复,即使可以执行多个动作。然而,对于每一个被执行的动作,工作对象应重复。

参与者只出现一次,工作对象重复

另一个有点意外的指导原则是,在象形语言中,if/else 条件不存在,这使得它成为一种基于场景的语言。

基本上,你需要绘制一个图表来指定你正在描述的场景。例如,假设你正在描述客户如何购买电影票。你可能有很多场景,如:

  • 最佳场景——顺利路径
  • 场景:客户用卡支付但被拒绝
  • 场景:客户用准确金额的现金支付
  • 场景:客户用超出金额的现金支付

你懂的。

此外,象形语言是基于范围的,也就是说,它取决于绘制图表时使用的范围。开始绘制图表时需要考虑三种范围:

颗粒度——用来表示图表中的故事的细节级别。你可以深入到任何想要的细节,但越详细,你会得到的场景就越多。

时间节点——用来指定你描述的过程所处的时间点。你可以根据当前的流程表示一个流程,过去的流程,或者你希望的流程……

领域纯度——你希望它有多数字化。让我举个例子来解释。再一次假设客户购买电影票的场景。使用纯粹范围的图表将描述用户如何在电影院的售票处购买票,而另一端则描述用户如何抓住笔记本电脑并访问电影院的网站购买票。

5 现在开始绘图

现在我们已经了解了象形语言,你应该开始工作坊,尝试研究你用户的特定流程。在此之前,你应该讨论用于绘制图表的范围。

让我们来看一个实际的例子。某天我们醒来,决定去汽车经销商那里买辆新车。问题是你不富有,无法一次性支付所有款项。因此,你需要要求一个可以分期付款的合同。使用象形语言,基本流程将如下所示:

领域故事讲述图表

如你所见,我们只使用了上述四个元素。通过这四个元素,我们能够描述整个流程。显然,我们并没有深入到太多细节,而且这是使用的纯粹范围。

一旦我们绘制了这个图表,就该开始识别界限上下文了。在这个例子中,我们可以将其分为两个BC:“风险评估”和“销售”。

正如我们在图表中所看到的,工作对象“合同”可能是一个实体,它有不同的动作。右边的一个动作是评估,左边的一个动作是签署。这提示我们,这两个动作实际上是不同的,因此应该在两个上下文中分别创建。

从这里开始,你应该将此应用到所有流程中,并开始编写更多的领域故事。

6 如何构建图表

纸上构建图表的方式:

“客户在电影院买爆米花”这个流程的一个实际示例:

如你所见,在纸张的右边部分,我记录了一些假设以及考虑的范围。

目录
相关文章
|
11月前
|
数据安全/隐私保护
如何把DDD应用到实际项目中来,例子中需要包含具体的领域模型设计,这么做的理由,以及一位这个设计而引进的坑
如何把DDD应用到实际项目中来,例子中需要包含具体的领域模型设计,这么做的理由,以及一位这个设计而引进的坑
144 4
|
2月前
|
存储 领域建模 数据库
当谈论DDD到底在谈论什么
DDD领域驱动设计是将业务领域概念和规则映射到软件设计的方法,能打通产品、设计、编码人员的信息壁垒。同时一套设计保持了业务和编码的一一对应。
55 1
|
3月前
|
缓存 架构师 中间件
成为工程师 - 如何做DDD领域驱动设计?
成为工程师 - 如何做DDD领域驱动设计?
产品第三版面向对象角度的DDD落地
我们应该关注谁来做事,而不是怎么做事
|
架构师 算法 测试技术
小团队也能做DDD-中篇
小团队也能做DDD-中篇
231 0
|
Java 机器人 程序员
大白话DDD(DDD黑话终结者)
大白话DDD(DDD黑话终结者)
357 0
|
Web App开发 机器学习/深度学习 数据可视化
万字长文解析,领域驱动设计(DDD)落地设计
领域驱动设计(简称 ddd)概念来源于2004年著名建模专家Eric Evans 发表的他最具影响力的书籍:《领域驱动设计——软件核心复杂性应对之道》(Domain-Driven Design –Tackling Complexity in the Heart of Software),简称Evans DDD,领域驱动设计思想进入软件开发者的视野。在将近20年的发展中领域模型设计一直占据着非常重要的位置,但其直接面向业务场景的设计思想,更适合在具有特定业务场景的模型构建。
|
设计模式 领域建模
DDD的模式与实践案例(1)
DDD的模式与实践案例(1)
1023 0
DDD的模式与实践案例(1)
|
设计模式
DDD的模式与实践案例(2)
DDD的模式与实践案例(2)
729 0
DDD的模式与实践案例(2)
|
测试技术
DDD的模式与实践案例(3)
DDD的模式与实践案例(3)
544 0
DDD的模式与实践案例(3)