豆瓣
扫码直接下载
翻译的跟shi一样.
Google翻译的吧。抖机灵的牛仔对话简直莫名其妙。我们现在用的,大都是贫血模型。还停留在能用就行的阶段,哪有什么设计。
写的有点啰嗦;译者4个月业余时间翻译了500多页的书,这个翻译质量看着有点...比如“xxx的名字长度小于所要求的。” 的啥?event sourcing,事件溯源,多常见的概念,书里居然翻译成“事件源”...真是google翻译的么
多年前,我在实习期间第一次听说了DDD,涉世未深的我以为是一门玄乎的,拿来标新立异的技术。在工作多年后,偶然看到书架上还从未被翻阅过的《领域驱动设计》,仿佛如获至宝。在软件开发中,我们时常过于强调某种技术某个框架,却忽视了捕捉到软件的核心业务。DDD中一直所强调的聚合,限界上下文等概念正是教我们如何用一种“通用语言”去实现软件的核心价值。也许我们与高手最大的区别在于,他们能将知识概念化,抽象化,理论化,系统化。
对软件开发中常见的情景进行了很好的抽象,归类。 虽然有些地方说得不够透彻,有些地方的说服力不够,还有些地方甚至误导严重(比如利用消息集成限界上下文时,通过事件发生时间来解决顺序问题的方案,如果消费端部署在多个节点,这个方案就是有问题的,或者很不完备,而这在目前互联网应用中是非常普遍的情况)。 但本书对如何应用DDD,如何站在更高的层次进行设计,如何权衡设计,进行了清晰的说明,并提出了切实可行的建议和原则。 一直在想老外为什么这么善于抽象、创造新名词,进而建立一套体系/思想/方法
又臭又长 而且没看出来哪落地了 写的零零散散的 加上蹩脚翻译 精简掉60%都没问题 2020.5-2020.8
真的不怎么样,没有人会按照这个按部就班的实施领域驱动设计吧,也许是我期望太高了。
浙江省图书馆
有些事情很难实现,会不会太纸上谈兵?
名为Implementing,感觉离落地太远,也可能自己境界不够,关于架构的讨论比较好看。
2015-08-24 专注业务架构而不是语言之争。
DDD的绝对力作,教你如何让DDD落地!
面向对象编程是金科玉律的年代已经过去了,虽然面向对象很重要,但是把它变成一个全面的方法论,我内心里面觉得领域驱动设计本质其实:就是抽象而已,可能程序员或者工程师觉得太抽象,其实从一个数学专业的来看,这根本只是很低层次的抽象而已,最多也就是19世纪前数学领域那种抽象程度,离群环域还很远。对于一些ERP或者业务非常面向B端的复杂系统,可能是需要领域驱动设计;对于比较新的互联网应用这个和快速迭代还是有些抵触的。
比较流畅,低于预期。
本书是一本讲DDD实践的好书,由浅入深引发我的思考,从战略建模和战术建模两个角度,让我重新审视了这些年自己做的项目。个人认为,要实现DDD首先团队成员们要站在同样的DDD的高度,至少要能够理解数据库只是对象持久化的一种实现方式,如果没有这个认识和共识,那么永远只是一个CRUD项目而已。本书阅读也是有门槛的,至少要懂得设计模式,另外也不能墨守成规,不能为了DDD而DDD,要从实际出发。没有银弹,以后的鲁还有很长。
可能书是好书,但感觉收获一般
实现领域驱动设计,先看精粹,再看此书
比预想的要好,不是理论的堆砌,不是陈词滥调。通过实例进行讲解,深入到每一种情况的处理,细节见真章,同时,让我感触比较深的是,它让我明白了领域设计更多的是业务层面的战略设计,他也不是一个狭义的概念,更多的是多一些细节的掌握,包括但不限于程序的结构设计和编写。
同事翻译的一本书,有点儿难懂。虽然现在DDD建模已经不必那么复杂了,了解一下DDD建模这几年时怎么由深到浅,是一种非常好的学习。
查漏补缺
> 实现领域驱动设计
16 有用 ever 2017-04-18 23:43:08
翻译的跟shi一样.
7 有用 卡莱 2017-10-23 21:34:19
Google翻译的吧。抖机灵的牛仔对话简直莫名其妙。我们现在用的,大都是贫血模型。还停留在能用就行的阶段,哪有什么设计。
3 有用 siisiv 2020-02-19 16:28:56
写的有点啰嗦;译者4个月业余时间翻译了500多页的书,这个翻译质量看着有点...比如“xxx的名字长度小于所要求的。” 的啥?event sourcing,事件溯源,多常见的概念,书里居然翻译成“事件源”...真是google翻译的么
2 有用 lazy_boy 2020-08-15 19:34:12
多年前,我在实习期间第一次听说了DDD,涉世未深的我以为是一门玄乎的,拿来标新立异的技术。在工作多年后,偶然看到书架上还从未被翻阅过的《领域驱动设计》,仿佛如获至宝。在软件开发中,我们时常过于强调某种技术某个框架,却忽视了捕捉到软件的核心业务。DDD中一直所强调的聚合,限界上下文等概念正是教我们如何用一种“通用语言”去实现软件的核心价值。也许我们与高手最大的区别在于,他们能将知识概念化,抽象化,理论化,系统化。
1 有用 ewon 2016-04-20 14:29:04
对软件开发中常见的情景进行了很好的抽象,归类。 虽然有些地方说得不够透彻,有些地方的说服力不够,还有些地方甚至误导严重(比如利用消息集成限界上下文时,通过事件发生时间来解决顺序问题的方案,如果消费端部署在多个节点,这个方案就是有问题的,或者很不完备,而这在目前互联网应用中是非常普遍的情况)。 但本书对如何应用DDD,如何站在更高的层次进行设计,如何权衡设计,进行了清晰的说明,并提出了切实可行的建议和原则。 一直在想老外为什么这么善于抽象、创造新名词,进而建立一套体系/思想/方法
3 有用 eminemheaton 2020-09-02 09:45:10
又臭又长 而且没看出来哪落地了 写的零零散散的 加上蹩脚翻译 精简掉60%都没问题 2020.5-2020.8
2 有用 嘉陵 2014-06-15 22:20:36
真的不怎么样,没有人会按照这个按部就班的实施领域驱动设计吧,也许是我期望太高了。
0 有用 benqteamilk 2014-09-08 20:07:34
浙江省图书馆
0 有用 深蓝 2016-05-09 19:13:03
有些事情很难实现,会不会太纸上谈兵?
0 有用 juntao.qiu 2014-09-24 10:41:24
名为Implementing,感觉离落地太远,也可能自己境界不够,关于架构的讨论比较好看。
0 有用 山海 2015-08-24 15:31:26
2015-08-24 专注业务架构而不是语言之争。
0 有用 杜魚 2014-03-30 12:10:42
DDD的绝对力作,教你如何让DDD落地!
0 有用 greatabel 2019-02-18 22:02:47
面向对象编程是金科玉律的年代已经过去了,虽然面向对象很重要,但是把它变成一个全面的方法论,我内心里面觉得领域驱动设计本质其实:就是抽象而已,可能程序员或者工程师觉得太抽象,其实从一个数学专业的来看,这根本只是很低层次的抽象而已,最多也就是19世纪前数学领域那种抽象程度,离群环域还很远。对于一些ERP或者业务非常面向B端的复杂系统,可能是需要领域驱动设计;对于比较新的互联网应用这个和快速迭代还是有些抵触的。
0 有用 doubin 2021-12-12 09:29:10
比较流畅,低于预期。
0 有用 骇客辉 2021-10-18 11:21:50
本书是一本讲DDD实践的好书,由浅入深引发我的思考,从战略建模和战术建模两个角度,让我重新审视了这些年自己做的项目。个人认为,要实现DDD首先团队成员们要站在同样的DDD的高度,至少要能够理解数据库只是对象持久化的一种实现方式,如果没有这个认识和共识,那么永远只是一个CRUD项目而已。本书阅读也是有门槛的,至少要懂得设计模式,另外也不能墨守成规,不能为了DDD而DDD,要从实际出发。没有银弹,以后的鲁还有很长。
0 有用 阿里阿里巴巴 2021-11-12 18:46:46
可能书是好书,但感觉收获一般
1 有用 飞翔在无限的蓝 2021-11-04 07:26:04
实现领域驱动设计,先看精粹,再看此书
0 有用 杨小帆 2022-01-20 09:31:58
比预想的要好,不是理论的堆砌,不是陈词滥调。通过实例进行讲解,深入到每一种情况的处理,细节见真章,同时,让我感触比较深的是,它让我明白了领域设计更多的是业务层面的战略设计,他也不是一个狭义的概念,更多的是多一些细节的掌握,包括但不限于程序的结构设计和编写。
0 有用 小郑 2022-10-03 19:52:59 加拿大
同事翻译的一本书,有点儿难懂。虽然现在DDD建模已经不必那么复杂了,了解一下DDD建模这几年时怎么由深到浅,是一种非常好的学习。
0 有用 颜小婧 2022-04-30 15:31:43
查漏补缺