软件设计之美
郑晔
推文科技技术VP,前火币网首席架构师
立即订阅
3458 人已学习
课程目录
已完结 36 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 软件设计,应对需求规模的“算法”
免费
课前必读 (3讲)
01 | 软件设计到底是什么?
02 | 分离关注点:软件设计至关重要的第一步
03 | 可测试性: 一个影响软件设计的重要因素
了解一个软件的设计 (4讲)
04 | 三步走:如何了解一个软件的设计?
05 | Spring DI容器:如何分析一个软件的模型?
06 | Ruby on Rails:如何分析一个软件的接口?
07 | Kafka:如何分析一个软件的实现?
设计一个软件—程序设计语言 (5讲)
08 | 语言的模型:如何打破单一语言局限,让设计更好地落地?
09 | 语言的接口:语法和程序库,软件设计的发力点
10 | 语言的实现:运行时,软件设计的地基
11 | DSL:你也可以设计一门自己的语言
加餐 | 再八卦几门语言!
设计一个软件—编程范式 (9讲)
12 | 编程范式:明明写的是Java,为什么被人说成了C代码?
13 | 结构化编程:为什么做设计时仅有结构化编程是不够的?
14 | 面向对象之封装:怎样的封装才算是高内聚?
15 | 面向对象之继承:继承是代码复用的合理方式吗?
16 | 面向对象之多态:为什么“稀疏平常”的多态,是软件设计的大杀器?
17 | 函数式编程:不用函数式编程语言,怎么写函数式的程序?
18 | 函数式编程之组合性:函数式编程为什么如此吸引人?
19 | 函数式编程之不变性:怎样保证我的代码不会被别人破坏?
加餐 | 函数式编程拾遗
设计一个软件—设计原则与模式 (7讲)
20 | 单一职责原则:你的模块到底为谁负责?
21 | 开放封闭原则:不改代码怎么写新功能?
22 | Liskov替换原则:用了继承,子类就设计对了吗?
23 | 接口隔离原则:接口里的方法,你都用得到吗?
24 | 依赖倒置原则:高层代码和底层代码,到底谁该依赖谁?
25 | 设计模式:每一种都是一个特定问题的解决方案
26 | 简单设计:难道一开始就要把设计做复杂吗?
设计一个软件—设计方法 (3讲)
27 | 领域驱动设计:如何从零开始设计一个软件?
28 | 战略设计:如何划分系统的模块?
29 | 战术设计:如何像写故事一样找出模型?
巩固篇 (3讲)
30 | 程序库的设计:Moco是如何解决集成问题的?
31 | 应用的设计:如何设计一个数据采集平台?
32 | 应用的改进:如何改进我们的软件设计?
结束语 (1讲)
结束语|那些没讲的事儿
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

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

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

角色:实体、值对象

我们的首要任务就是设计角色,在战术设计中,我们的角色就是各种名词。我们在初学面向对象的时候,课本上的内容就告诉我们要识别出一个一个的模型,其实,就是让我们识别名词。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件设计之美》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(11)

  • 骨汤鸡蛋面
    感觉郑老师最厉害的地方就是讲出了why,而不单是说how。很多文章会说“实体有唯一标识符”,很正确又无用。 只有结合了“是聚合的,我们可以一次都拿出来;不是聚合的,我们就靠标识符按需提取”,我才有了恍然大悟的感觉。
    2020-08-03
    1
    6
  • 桃子-夏勇杰
    设计在我们这个行业实在太缺失,因为几乎没人懂,软件开发人员最多,产品经理这几年也发展下来也多了不少,软件设计大家还在摸着石头过河。

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

    2020-08-06
    4
  • 布凡
    结合 张逸老师的《领域驱动设计实践》,完美

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

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

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

    2020-08-05
    2
  • 阳仔
    总结一下
    战术设计首先识别角色(名词),也就是实体和值对象,然后理清楚角色之间的关系,也就是聚合。
    最后寻找动词使用领域服务,领域事件等将各个角色的行为组织起来

    作为客户端开发者,我觉得这几讲我都感觉看懂了,但是又好像没懂,可能是对 DDD 相关概念的理解还不是很深刻,没有实际业务的操作支撑

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

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

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

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

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

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

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

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

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

    2020-08-05
    1
  • 胖子
    领域事件可以帮助我们让系统达成最终一致的状态。怎么理解?能举例说明一下吗?
    2020-08-03
    1
  • 青生先森
    老师,总能把复杂问题讲得如此简单明了,实在佩服其功力。
    2020-08-12
收起评论
11
返回
顶部