Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >可落地的DDD(7)-战术设计上的一些误区

可落地的DDD(7)-战术设计上的一些误区

作者头像
方丈的寺院
发布于 2022-11-08 05:22:20
发布于 2022-11-08 05:22:20
6320
举报
文章被收录于专栏:方丈的寺院方丈的寺院

背景

几年前我总结过DDD战术设计的一些落地经验可落地的DDD(5)-战术设计,和一次关于聚合根的激烈讨论最近两年有些新的落地体验,回过头来发现,当初对这些概念的理解还是没有深入,这篇文章重新阐述下。

之前理解不到位的点有

  1. 战术设计的各个模块是的协作关系
  2. 哪些是问题空间问题,哪些是方案空间问题边界没有划分清楚。
  3. 实体和聚合根的区别理解不深刻,实体和聚合根建模的方法不对。

以上问题将会在下文解释清楚。

战术设计拆解

DDD的战术设计即设计某个子域的领域模型以及代码落地。领域事件、领域对象、聚合根、实体、值对象、领域服务、工厂、资源库等这些概念都属于这个范畴。

笔者将这些概念重新分层组装了下,如下图所示。

首先将整体分成两部分,问题空间和方案空间。

  1. 问题空间即领域建模。是对业务问题的描述,以及我们如何对这些问题进行抽象。这些是需要在业务、产品、开发都必须达成一致的,与具体的技术方案无关。
  2. 方案空间即如何用技术手段来解决问题,与具体技术的实现有关。

问题空间即领域建模,是通过实体、值对象、领域服务、领域事件来表达。

  1. 实体和值对象是模型对象,实体是重中之重,包括核心模型数据、行为、状态。之所以要区分实体和值对象,是为了降低复杂度,因为值对象是个常数对象,不需要花太多精力。注意某个对象在某个领域内是个值对象,在另外的领域可能是个实体,所以脱离领域上下文,说某个对象是值对象,肯定是不对的,比如大家常说的地址是个值对象,这一定是对的吗?
  2. 领域事件即实体产生的事件
  3. 领域服务包括一些逻辑的计算,和业务策略。比如商业决策逻辑、业务流程等。

方案空间即如何解决问题,实现领域模型与代码的映射。设计与实现的一致性。主要通过工厂,聚合,资源库来表达。

  1. 聚合是对实体、值对象的封装。领域外部对领域对象所有访问都基于聚合来。如基础设施层操作聚合进行数据保存。其他领域引用聚合对象数据。聚合的设计一般是围绕着技术来的,比如聚合对象事务性。
  2. 工厂,复杂对象的创建工厂类
  3. 资源库,对聚合的操作。

从笔者的实践角度来说,落地DDD过程中,问题空间比方案空间更重要,收益更大。因为通常我们吐槽的某些代码写的烂,贫血模型。背后并不是因为没有用DDD,而是问题空间没有定义好,对于业务没有深刻理解,导致模型抽象不足。

如何建模

为什么要建模

通常在某个子域落地DDD,我们会按照业务分析-》用例分析-》领域建模(问题空间) -》技术落地(方案空间)这些步骤来操作。但其实即使我们不在代码里落地DDD,只用前面3步维护一个子域内的领域模型也同样能够带来很多收益,包括但不限于

  1. 统一业务组各个角色的认知,业务、产品、开发大家对同一概念的认知是一致的。
  2. 指导开发工作的拆分。

比如在淘宝有个血的教训,至今这个历史债还无法被修复。早期在淘宝开店。一个卖家只能开一个店。卖家和店铺是两个领域对象,关系是1:1。店铺服务觉得是1:1的关系,对外提供的服务有根据sellerId获取店铺信息,所以其他调用方就无意识的直接引用了卖家id,这样也可以拿到店铺。导致shopId被等同于了sellerID。这个误引用发生在成千上万个地方,最后导致后续需要支持一个卖家开多店铺时无法支持。只能通过其他trick方式实现。

以之前介绍过的CRM领域 来讲解。省略业务分析,直接拿到用例。

用例分析

按用户角色罗列所有的用例,用来推导模型、以及模型之间的关系。领域模型建立好了,需要根据列出的用例来走查一遍,要确保所有的用例都能走通。完整的用例集才能推导出正确的模型,所以当有变化时,首先调整用例集,再来修改领域模型

建模

领域建模就是定义模型对象,以及模型对象之间的关联关系。分两步建模,第一步通过名词找模型对象。第二步通过动词、形容词分析对象关联关系

名词

通常反复出现的主语和宾语中的名词就是模型对象,比如市场人员创建一个活动,活动就是一个模型对象。当然定语中出现的名词也可能是模型对象。

1.名词的定义一定要清晰。比如说crm领域有通用的名词叫商机。但是你对口的产品经理不熟悉crm领域,新造了一个词,那你要及早纠正他。

2.名词的含义在限界上下文内语义唯一,在不同的上下文中概念就不一定一样了。比如市场人员创建的活动,和做营销时创建的活动就不一定。

动词、活动

1个市场人员可以创建多个活动,所以市场人员和活动关联关系是1对多。两者独立存在,普通关联关系。

这里为了简化描述,只列了市场活动、线索、客户、商机这些域。用户、角色、权限、数据分析这些域先忽略了。

在线教育crm领域模型 (1).png

产出物

在推导的过程中,我们是按照自下向上的方式推导的,最后我们呈现出来的结果是按照如下方式

  1. 域名词 市场活动: 市场人员为了展示公司形象、推广公司产品,获取线索而举办的活动。一个活动中可以创建多个线索。

线索: 销售人员基于线索发掘潜在客户,多个线索转换为一个客户。线索可以由一个市场活动生成,或者其他渠道。

客户:有意向购买公司产品的用户,销售人员可以通过跟进客户,转化销售机会。

销售机会:更高质量的线索,有机会签单。可以通过客户转换得到,也可以通过其他渠道来获取

  1. 领域模型 如上图
  2. 主要领域状态转换。因为复杂的领域对象生命周期以及一些跨领域对象交互情况在领域模型图中表达不出来,所以需要借助额外的图来表达。

在线教育crm领域状态.png

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-07-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 方丈的寺院 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
DDD 领域驱动设计落地实践系列:战略设计和战术设计
通过前面的文章介绍,相信大家对于什么是 DDD 有了初步的了解,知道它是一种微服务的架构设计方法论,为我们解决如何建立领域模型,如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用 DDD,可能大家还是一脸懵 B 的状态,因此从本文开始以及后面的文章将对如何进行 DDD 落地进行详细的阐述。在这其中还是会涉及到 DDD 中的一些重要概念,原本想着在一篇文章中介绍所有的概念,但是我觉得,概念总是在它该出现的时候出现才会让大家印象深刻,否则这些概念只是死板的概念,我们不清楚他为什么出现以及可以解决什么问题。
慕枫技术笔记
2023/03/20
9590
DDD 领域驱动设计落地实践系列:战略设计和战术设计
万字长文助你上手软件领域驱动设计 DDD
作者:faryrong,腾讯 CSIG 后台开发工程师 最近看了一本书《解构-领域驱动设计》,书中提出了领域驱动设计统一过程(DDDRUP),它指明了实践 DDD 的具体步骤,并很好地串联了各种概念、模式和思想。因此,我对书本内容做了梳理、简化,融入自己的理解,并结合之前阅读的书籍以及实践经验,最终形成这篇文章。希望可以帮助大伙理顺 DDD 的各种概念、模式和思想,降低上手 DDD 的门槛。 1.背景 领域驱动设计(DDD)由 Eric Evans 提出,并一经《领域驱动设计:软件核心复杂性应对之道》的发布
腾讯技术工程官方号
2022/03/29
2.1K0
深度解析DDD中台和微服务设计
导读:本文来源于 2020 年第四届 DDD 中国峰会主题演讲:《当中台遇上 DDD,如何设计微服务》。DDD 非常强调统一语言,而 DDD、中台与微服务产生于不同的时代,三者分别属于不同的方法体系,而方法论的融合首要在于建立统一语言,那么:
IT阅读排行榜
2021/02/05
9390
深度解析DDD中台和微服务设计
DDD实战之八:冲刺 1 战术之聚合设计
束善杭(网名:深清秋):21年老码农,持续创业中。热爱写代码、热爱做软件架构设计、热爱做软件产品设计,一旦做这些就很容易进入“心流”状态,忘了吃喝拉撒、废寝忘食!最近决定把自己的一些代码或设计经验分享出来,希望对大家有用!个人秉承的职业理念:通过自己给自己加班,提升自己的稀缺性,其实所有人都可以突破年龄障碍!
张逸
2023/03/23
5670
DDD实战之八:冲刺 1 战术之聚合设计
领域驱动设计(DDD)理论启示
过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段,以应对不断增长的业务需求和容量、高可用等技术需求,现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力,主流程的新需求越来越少,个性化需求和非标准化流程的数据源和服务接入的需求越来越多,有些甚至是京东零售体系外的,同时通天塔技术和产品也在积极主动寻求变化和创新,这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目:通天塔积木,旨在构建一个基于完全开放的前端SDK和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方IT环境的活动搭建解决方案,这套方案的初衷和设计理念也契合了京东国际化赋能和PaaS化的战略。目前通天塔积木已经取得阶段性成果,已开始赋能京东国内和国际站,但如何应对异常复杂的积木业务逻辑和不可预知的业务变化,构建业务和底层技术基础实施的完全解耦的系统,一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源头,思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标,DDD这个词不知不觉映入了我的眼帘。
物流IT圈
2020/03/16
1.8K0
领域驱动设计(DDD)理论启示
领域驱动设计阶段知识总结
领域用来限定业务范围,范围就是边界,这就是DDD不断强调边界的原因。 DDD的领域就是这个边界内要解决的业务问题域。在研究和解决业务问题时,DDD会按照一定的规则将业务领域进行细分,当领域细分到一定程度后,DDD会将问题范围限定在特定的边界内,在这个边界内建立领域模型,进而用代码实现领域模型,解决相应业务问题。 业务范围可能也很大,如果把这个范围看成是一个空间的话,那它同时存在“问题空间”和“解决方案空间”。问题空间是从业务需求方面来看,而解决方案空间是从实现软件方面来看,两者有一些细微的区别的,最终用子域来划分问题空间,用限界上下文来划分解决方案空间。
jack.yang
2025/04/05
1130
领域驱动设计-上
随着软件系统越来越庞大,需求越来越模糊,代码越来越混乱,测试越来越困难,技术演进基本不可能,而其中大型复杂的软件项目更容易走向系统老化的过程,形成需求难、开发难、测试难、创新难,单体架构局部业务膨胀可以拆成微服务,那么微服务局部业务膨胀又应该怎么做?DDD之所以火,即能解决微服务解决不了的问题。DDD是为了解决快速变化、复杂系统的设计问题。
用户7353950
2022/06/23
4900
领域驱动设计-上
领域驱动设计精粹(中)
领域驱动设计学习拦路虎之一就是众多的概念,第一次接触这些概念会有一定的理解成本,不过正是这些概念支撑起的领域驱动设计,接下来会以电商为例对其中的核心概念做介绍。
知一
2022/09/23
9520
领域驱动设计精粹(中)
DDD实现之路
编者按:这篇文章最早撰写于2014年,作者也是《实现领域驱动设计》的译者。几年过去了,DDD在坊间依然方兴未艾,然而它的复杂性所引发的误解也层出不穷。对于一些基本概念的澄清甚至溯源,会帮助我们回到起点,对它展开新的认识。
ThoughtWorks
2021/02/08
4780
DDD在大众点评交易系统演进中的应用
本文主要涉及境外出行、商场团购和内容商业化等三类交易业务场景。在大众点评App里,在境外城市站有美食、购物、商场、景点、门票、当地玩乐等频道入口,可以购买境外出行交易产品,在境内的逛街/商场频道可以找到商场团购优惠以及商场团购代金券。
美团技术团队
2024/05/15
2390
DDD在大众点评交易系统演进中的应用
DDD实战课--学习笔记
我认为,要想应用 DDD,首要任务就是要吃透 DDD 的核心设计思想,搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型,微服务是业务模型的系统落地,DDD 是一种设计思想,它可以同时指导中台业务建模和微服务设计,它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性,先有领域模型然后才有微服务,而不是脱离领域模型来谈微服务设计。
郑子铭
2021/03/12
1.1K0
DDD实战课--学习笔记
DDD 领域驱动设计落地实践:六步拆解 DDD
相信通过前面几篇文章的介绍,大家对于 DDD 的相关理论以及实践的套路有了一定的理解,但是理解 DDD 理论和实践手段是一回事,能不能把这些理论知识实际应用到我们实际工作中又是另外一回事,因此本文通过实际的业务分析把之前文章中涉及的理论和手段全部带着大家走一遍,我想通过这种方式,让大家实际的感受下 DDD 落地过程中会遇到哪些问题以及我们应该怎样去解决这些问题。
慕枫技术笔记
2023/03/20
8910
DDD 领域驱动设计落地实践:六步拆解 DDD
一文带你落地DDD
hello,everyone,好久不见。最近几周部门有个大版本发布,一直没有抽出时间来写博。由于版本不断迭代,功能越做越复杂,系统的维护与功能迭代越来越困难。前段领导找我说,能不能在架构上动手做做文章,将架构迁移到DDD。哈哈哈哈,当时我听到这个话的时候瞬间来了精神。说实话,从去年开始从大厂的一些朋友那里接触到DDD,自己平时也会时不时的阅读相关的文章与开源项目,但是一直没有机会在实际的工作中实施。正好借着这次机会可以开始实践一下。
柏炎
2022/08/23
8390
一文带你落地DDD
DDD战术篇:领域模型的应用
领域驱动设计DDD在战术建模(后文简称建模,除非特别说明)上提供了一个元模型体系(如下图),通过这个元模型我们会对战略建模过程中识别出来的问题子域进行抽象,而通过抽象来指导最后的落地实现。 (DDD构
ThoughtWorks
2018/04/17
1.2K0
DDD战术篇:领域模型的应用
《解构领域驱动设计》第二章
应对复杂度的挑战,或许是构建软件的过程中唯一亘古不变的主题。为了更好地应对软件复杂度,许多顶尖的软件设计人员与开发人员纷纷结合实践提出自己的真知灼见,既包括编程思想、设计原则、模式语言、过程方法和管理理论,又包括对编程利器自身的打磨。毫无疑问,通过这些真知灼见,软件领域的先行者已经改变或正在改变我们构建软件的方法、过程和目标,我们欣喜地看到了软件的构建正在向着好的方向改变。然而,整个客观世界的所有现象都存在诸如黑与白、阴与阳、亮与暗的相对性,任何技术的发展都不是单向的。随着技术日新月异向前发展,软件系统的复杂度也日益增长。中国有一句古谚:“道高一尺,魔高一丈。”又有谚语:“魔高一尺,道高一丈。”究竟是道高还是魔高,就看你是站在“道”的一方,还是“魔”的一方。
张逸
2023/03/23
7260
《解构领域驱动设计》第二章
领域驱动设计(DDD)在有赞教育线索资源管理的实践
教育领域,完整的流程板块包括:招生拓客、线索管理、教务管理、学员管理、互动督学、口碑传播。首先,在招生拓客环节,会通过线上营销工具或线下地推方式收集潜在的学员线索信息,并录入到线索管理系统中。在线索管理环节,会采用线索资源管理系统对收集的线索做统一管理,并将潜在学员转为真正的学员,提供给后续的教务管理使用。可见,线索管理在整个教育领域承担着承上启下的作用,重要性不言而喻。
有赞coder
2020/08/25
9430
领域驱动设计(DDD)在有赞教育线索资源管理的实践
领域驱动实践总结(基本理论总结与分析V+架构分析与代码设计+具体应用设计分析)
2.实现方式:DDD 分层架构、整洁架构、CQRS 和六边形架构等 (我们采用DDD 分层架构)
全栈程序员站长
2022/08/10
8260
领域驱动实践总结(基本理论总结与分析V+架构分析与代码设计+具体应用设计分析)
领域驱动实践总结(基本理论总结与分析+架构分析与代码设计+具体应用设计分析V)[通俗易懂]
领域驱动设计DDD是一种设计思想,它可以同时指导中台业务建模和微服务设计(中台本质是业务模型,微服务是业务模型的系统落地),领域驱动设计强调领域模型和微服务设计的一体性,先有领域模型然后才有微服务,而不是脱离领域模型来谈微服务设计。
全栈程序员站长
2022/07/22
6430
领域驱动实践总结(基本理论总结与分析+架构分析与代码设计+具体应用设计分析V)[通俗易懂]
领域驱动设计(DDD)实践之路(一)
领域驱动设计(Domain Driven Design,DDD)其实并非新理论,大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年,距今已十余年时间。与现在的分布式、微服务相比,绝对是即将步入中年的“老家伙”了。
2020labs小助手
2020/02/24
1.4K0
探秘微信业务优化:DDD从入门到实践
引言 | 本文作者从微信团队维护的带货类项目所遇卡点出发,尝试用领域驱动设计方法(简称DDD),保障在快节奏、多人协作的项目迭代中,维持系统的可维护性、可拓展性、高内聚低耦合和稳定性。作者首先剖解相关概念原理,之后代入亲身参与的微信团队实际项目、围绕DDD方法进行优化实操。 DDD 全称 Domain-Driven Design,中文叫领域驱动设计,是一套应对复杂软件系统分析和设计的面向对象建模方法论。它由Eric Evans于2003年提出,但一开始不愠不火。直到MartinFowler于2014年发表论
腾讯云开发者
2022/12/09
1.1K0
探秘微信业务优化:DDD从入门到实践
推荐阅读
相关推荐
DDD 领域驱动设计落地实践系列:战略设计和战术设计
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档