DDD中领域故事的作用

本文涉及的产品
多模态交互后付费免费试用,全链路、全Agent
简介: 【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 如何构建图表

纸上构建图表的方式:

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

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

目录
相关文章
|
设计模式 前端开发 关系型数据库
【DDD】全网最详细2万字讲解DDD,从理论到实战(代码示例) 3
【DDD】全网最详细2万字讲解DDD,从理论到实战(代码示例)
5139 2
|
SQL 监控 网络协议
线上故障如何快速排查?来看这套技巧大全
有哪些常见的线上故障?如何快速定位问题?本文详细总结工作中的经验,从服务器、Java应用、数据库、Redis、网络和业务六个层面分享线上故障排查的思路和技巧。较长,同学们可收藏后再看。
线上故障如何快速排查?来看这套技巧大全
|
领域建模 API 数据安全/隐私保护
DDD的函数式编程实现
【8月更文挑战第16天】
174 0
DDD的函数式编程实现
|
10月前
|
消息中间件 供应链 测试技术
图解 DDD,这一篇总结太全面了!
DDD领域驱动是非常热的架构设计,微服务也有大量涉及,本文详细解析领域驱动设计(DDD),涵盖DDD原理、实践步骤及核心概念等,帮助更好地管理复杂业务逻辑。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
图解 DDD,这一篇总结太全面了!
|
缓存 NoSQL 安全
|
架构师 开发者
【悬念揭秘】DDD:那片隐藏在软件深处的业务乐土——.NET项目如何借力领域驱动设计,让复杂业务逻辑迎刃而解?
【8月更文挑战第28天】领域驱动设计(DDD)在.NET项目中的应用聚焦于将业务领域知识与软件开发紧密结合,通过构建清晰的领域模型管理复杂业务逻辑。DDD的核心概念包括限界上下文、聚合、实体等,确保模型与实现的统一。在.NET中,通过CQRS和事件源等模式提高系统响应性和可扩展性,实现业务事件驱动的解耦与协作。DDD不仅是一种设计方法,更是要求开发者深入理解业务的文化,助力.NET项目应对复杂挑战,实现业务与技术的融合。
172 6
|
设计模式 Java 开发者
如何在Java项目中实现领域驱动设计(DDD)
如何在Java项目中实现领域驱动设计(DDD)
|
12月前
|
架构师
DDD建模系列(一)
DDD建模系列(一)
|
敏捷开发 监控 架构师
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(构建领域知识)
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(构建领域知识)
344 0
|
11月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。