软件设计之美
郑晔
开源项目 Moco 作者
19890 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

29 | 战术设计:如何像写故事一样找出模型?

你好,我是郑晔!
在上一讲中,我们讲了 DDD 中的战略设计,学习如何将识别出来的不同模型放到不同的限界上下文中。那么,接下来,我们就该做更具体的工作了,也就是如何设计模型。在 DDD 中,把具体的模型找出来的做法有一个更响亮的名字:战术设计。
战术设计同样也包含了很多概念,比如,实体、值对象、聚合、领域服务、应用服务等等。有这么多概念,我们该如何区分和理解他们呢?我们同样需要一根主线。
其实,我们可以把战术设计理解成写一个故事。你知道怎样去写个故事吗?写故事通常都是有一定套路的。我们要先构建好故事的背景,然后,要设定不同的角色,接下来,创建角色之间的关系,最后,我们要安排人物之间互动起来,形成故事。
对于战术设计而言,故事的背景就是我们面对的领域问题,剩下的就是我们在这个故事背景下,要找出不同的角色,找出角色之间的关系,让它们互动起来,这样,我们就有了故事,也完成了战术设计。
接下来,我们就来看看,战术设计这个故事模板,我们应该怎么填?

角色:实体、值对象

我们的首要任务就是设计角色,在战术设计中,我们的角色就是各种名词。我们在初学面向对象的时候,课本上的内容就告诉我们要识别出一个一个的模型,其实,就是让我们识别名词。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

领域驱动设计(DDD)中的战术设计扮演着重要角色,类似于编写故事,通过识别实体、值对象、聚合和聚合根等角色,构建出一个完整的“故事”。在战术设计中,首先要识别出实体和值对象,实体是能够通过唯一标识符标识出来的对象,而值对象则表示一个值,没有标识符。接着,要考虑这些角色之间的关系,通过聚合将多个实体或值对象组合在一起,保证它们同生共死,而聚合根则是从外部访问这个聚合的起点。这种设计思路有助于解决一对多问题,使得设计更加符合业务需求,而不是仅仅从技术角度出发。通过对战术设计的理解,可以更好地进行领域建模和系统设计,提高系统的可维护性和扩展性。文章还介绍了领域事件、领域服务、工厂、仓库和应用服务等概念,以及它们在战术设计中的作用。这些内容构成了DDD中的战术设计的核心要点,为读者提供了对DDD基础概念之间关系的基本认识。文章最后提到了一些思考题,鼓励读者按照战术设计的模板,简要描述自己的项目,以加深对战术设计的理解。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件设计之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(27)

  • 最新
  • 精选
  • 布凡
    结合 张逸老师的《领域驱动设计实践》,完美

    作者回复: 我和张逸是多年老友,他太能写了。

    2020-08-10
    4
    22
  • 桃子-夏勇杰
    设计在我们这个行业实在太缺失,因为几乎没人懂,软件开发人员最多,产品经理这几年也发展下来也多了不少,软件设计大家还在摸着石头过河。

    作者回复: 大家都不容易。

    2020-08-06
    12
  • Demon.Lee
    想到两点,请老师指正。 1. 订单和订单项的例子中,订单项也是一个实体,而不是值对象吧,因为订单项中的各个属性有可能被修改,比如价格或数量,但它还是这个订单项。无论是存储在mongodb的一张table中,还是mysql里面的两张table中。 2. 结合老师的分析,我又想到了另一个例子,比如当前这边文章(Article)和文章评论(ArticleComment)。 从聚合概念上分析,文章是作者创建的,而评论是读者创建的,但如果文章被删除了,那么这些评论也就跟着要删除,所以他们不同生但共死。从识别聚合上分析,获取文章时,也无法一次性把所有评论获取到。

    作者回复: 这个理解没问题,非常棒!

    2020-08-11
    2
    10
  • jakimli
    请教一下,领域服务和应用服务的区别理解的不是很到位,应用服务负责协调领域对象合领域服务来完成各种业务动作,这种协调是否也是业务逻辑呢?

    作者回复: 稳定的部分放到领域服务里,易变的部分放到应用服务里。 举个例子,下单的过程包括下了商品订单之后,要发起支付。在这个过程里面,下商品订单和下支付订单两个过程就是领域服务,因为它们基本上是不变的,但下商品订单之后就立即下支付订单,这就属于一个过程的协调了,属于易变的部分,也可能下商品订单之后,再经过系列的其他过程再支付,所以,下单过程属于应用服务。

    2021-01-15
    2
    6
  • 老师,我们平时工作中的那种不怎么复杂的公司内务管理系统可以用Ddd的思想设计和开发,合适吗?如果没打算微服务的话

    作者回复: 这种普通的业务系统,用DDD是非常合适的。这和微服务没有关系,你可以把所有子域都放在一个限界上下文里。

    2020-08-05
    5
  • 三生
    感觉应用服务才是业务的实现者,领域服务是提供者,老师如何理解上面的

    作者回复: 从大部分人习惯的角度看,确实是这样的,因为应用服务常常对应着你的API。但核心是领域服务才是核心,是不可替换的,而应用服务则可能根据实际的情况发生改变。

    2020-08-03
    4
  • 大米
    “不是聚合的,我们就靠标识符按需提取”, 用CQRS落地DDD的话,如果按标识符去查询模型获取数据,有可能获取的不是最新的数据(因为写模型更新了,但查询模型更新是有延迟的),像这种极限情况会有什么问题吗?难道应该去通过命令去查询写的模型?怎么去理解和解决这种情况呢?

    作者回复: CQRS的话,你追求的是最终一致性,读这端拿到的你就应该认为它是最新数据。显然,如果你的目标是强一致,就别考虑CQRS。

    2020-08-05
    3
  • 阳仔
    总结一下 战术设计首先识别角色(名词),也就是实体和值对象,然后理清楚角色之间的关系,也就是聚合。 最后寻找动词使用领域服务,领域事件等将各个角色的行为组织起来 作为客户端开发者,我觉得这几讲我都感觉看懂了,但是又好像没懂,可能是对 DDD 相关概念的理解还不是很深刻,没有实际业务的操作支撑

    作者回复: 需要配合其他更具体的DDD材料进一步学习。

    2020-08-04
    3
  • Demon.Lee
    想了想,从停车管理系统来看,车牌号(比如:京A123F9),感觉是一个值对象,它的值变化了,就不再是这个车牌了,按车牌进行收费。 但车子可以换牌,此时我觉得把车牌设计成实体更好,车牌与不同的车有关联关系,在关联表里面有车辆Id,状态,生失效时间等。出入记录表中可以不用记录这个关联 id,只用车牌号,但查询出入历史记录,找到那辆车,需要在关联表上进行状态和时间上的过滤。 不过,这种换牌的概率很低。老师,您觉得我的理解是否有问题吗?谢谢。

    作者回复: 值对象是车牌号,实体是车牌。

    2021-11-01
    2
    1
  • 82
    老师讲的很棒!有股醍醐灌顶的感觉!这门课已经物超所值!

    作者回复: 欢迎把它分享给更多的朋友,大家一起前行!

    2020-08-10
    1
收起评论
显示
设置
留言
27
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部