如何落地业务建模
徐昊
ThoughtWorks中国区CTO
新⼈⾸单¥59.9
1612 人已学习
课程目录
已更新 5 讲 / 共 22 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词|为什么你需要学习业务建模?
免费
旧约:“前云时代”的领域驱动设计 (4讲)
01|领域驱动设计到底在讲什么?
02|统一语言是必要的吗?
03|我们要怎么理解领域驱动设计?
04|跨越现实的障碍(1):要性能还是要模型?
如何落地业务建模
15
15
1.0x
00:00/00:00
登录|注册

04|跨越现实的障碍(1):要性能还是要模型?

你好,我是徐昊。今天我们来聊聊通过关联对象(Assocation Object)建模聚合(Aggregation)。
在前面三节课,我们学习了领域驱动设计中的“两关联一循环”:模型与软件实现关联;统一语言与模型关联;提炼知识的循环。其中,统一语言与提炼知识的循环作为一种更为平衡的权责关系,促进了业务方与技术方更好的协作。而这一切又是以模型与软件实现关联为基础。
然而落地到实践中,关联模型与软件实现总有一些让人纠结与苦恼的地方。引起这些苦恼的主要原因是架构风格的变化。我们已经从单机时代过渡到了多层单体架构,以及云原生分布式架构,但我们所采用的建模思路与编程风格并没有彻底跟上时代的步伐,这种差异通常会以性能问题或是代码坏味道的形式出现。
如果我们想要真正发挥出领域驱动设计的作用,就需要在不同架构风格下,找到能够维持模型与软件实现统一的办法。这也是这个领域常看常新,总能产生新实践的原因。
因而接下来,我会用三节课来介绍一组实现模式,帮助我们应对从单机架构过渡到多层架构,保持模型与软件实现的关联。这些模式也是我们后面学习在微服务和云原生时代,实施领域驱动设计方法的基础。
今天这节课,我们就先从关联对象这一方法开始讲起。关联对象是一个古老的设计 / 分析模式,Martin Fowler 在《分析模式》中讨论过它。Peter Coad 将它视为一种常见的业务构成模式,并应用到业务分析中。而我大概从 2005 年开始,使用它建模领域驱动设计中的聚合与关联关系,以解决领域模型(Domain Model)中对技术组件的封装问题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
该试读文章来自付费专栏《如何落地业务建模》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥59.9
立即订阅
登录 后留言

精选留言(3)

  • 狩月
    这个模式很接地气啊!期待更多内容
    2021-07-01
  • 狩月
    有点像控制的更精细的ORM Lazyload?
    2021-07-01
  • 老师,请问如果不是访问数据库,而是说技术上需要调用RPC,或者去缓存例如REDIS取数据,这样的逻辑要怎样封装呢

    作者回复: 也可以转换为数据视角 然后通过关联对象封装

    2021-07-01
收起评论
3
返回
顶部