文章吧-经典好文章在线阅读:《领域驱动设计》读后感锦集

当前的位置:文章吧 > 原创文章 >

《领域驱动设计》读后感锦集

2020-07-18 23:54:01 来源:文章吧 阅读:载入中…

《领域驱动设计》读后感锦集

  《领域驱动设计》是一本由埃文著作人民邮电出版社出版的平装图书,本书定价:69.00元,页数:369,特精心网络整理的一些读者读后感希望大家能有帮助

  《领域驱动设计》精选点评

  ●很懵……

  ●拿货运cargo举例和银行业贷款loan举例的地方一知半解。讲理论知识的4-6章和面向对象以及设计模式的知识有点重合,所以到底这本书到底在讲啥。。。

  ●读完不知道怎么落地,功力不够 继续努力

  ●很多概念无法深入理解期待某天能顿悟作者思想

  ●从大学读到现在才读完的一本书…这本书不是教抽象抽象再抽象,而是传扬规范化领域概念并引入到软件设计中的一种思想。其实现在已经是很普遍做法了…

  ●实在难啃

  ●第一遍细读完成,爽!

  ●领域经典之作

  ●这本书不仅仅是各种“模式语言”的列举,还提出了软件开发中的一些“洞见”,读后令人印象深刻

  ●需要做过一两个中大规模系统过后,带着疑问来看这本书,会有不小的收获

  《领域驱动设计》读后感(一):很受用

  目前正在做敏捷交付,这本书对敏捷方式支持简直是完美对接形容.欢迎广大程序认真仔细的阅读

  目前正在做敏捷交付,这本书对敏捷方式的支持简直是完美对接来形容.欢迎广大程序猿认真仔细的阅读。

  目前正在做敏捷交付,这本书对敏捷方式的支持简直是完美对接来形容.欢迎广大程序猿认真仔细的阅读。

  《领域驱动设计》读后感(二):其实是一种方法论

  很多年前读过,那时候没有懂。 现在再读,里面很多设计上的手法和模式已经成为常识,但其作为方法论的那部分历久而弥新,仍然极有价值

  我理解的主要思想包括:

  一、创建共同语言: 领域专家和开发人员用同一种语言讨论问题。同一概念只有一个术语表达,一个术语准确表达一个概念。

  二、模型驱动开发: 模型既设计、代码与设计一致

  为了达到第二个目的,用这种方法论做出的模型必须既能让领域专看懂(因此需要屏蔽技术细节),又要能指导开发(因此必须包含有足够的软件设计要素),所以作者提出的建模方法没有规定建模的符号(UML不是必须的),但是规定了必须包含的一些组成要素。

  1、架构

  2、实体和值对象

  3、关联和聚合以及repository

  4、服务

  总的来说,是一种非常实用的,自顶向下的设计方法。

  《领域驱动设计》读后感(三):观点摘录

  软件最有价值部分是的领域模型部分。软件开发应该围绕这个核心进行组织,这是领域驱动设计的核理念

  这本书有价值的地方甚多,值得反复细细揣摩,书中最重要观点,摘录如下

  1.软件开发复杂性根本原因是问题领域本身错综复杂控制复杂性的关键是有一个好的领域模型,此模型不应该仅仅停留在领域的表面,而是要透过表象抓住领域的实质结构,从而为软件开发人员提供他们所需的支持,

  2.开发人员之间对话,领域专家之间讨论,以及代码本身表达,都应该基于同一种语言,来自一个共享的领域模型

  3.不能把模型仅仅作为理解工具,而应该严格按基础模型编写代码。模型驱动设计寻求分析和设计的合一,程序设计,以至代码本身,都与模型密不可分。

  4.由于领域模型的重要性,需要有意识的将领域对象与系统中其他对象分离,开发者借助各种各领域基础模型(实体「Entity」,值对象「Value Object」,服务「Service」,包「Package」等)以及各种领域对象生命周期管理策略(聚合「Aggregate」,工厂「Factory」,存储库「Repository」等)来消除模型和现实间的鸿沟

  5.模型的构建不可能一步到位,真正强大的领域模型是随着时间演讲的,即使是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法。--理解的逐步深入,重构的必然与重构的方向

  6.隐式概念的挖掘办法:倾听语言;检查不足之处;思考矛盾之处;查阅书籍;不要固执己见,尝试,再尝试!

  7.可建模概念的种类:经常被领域专家提及的--事物、行为、约束、过程。

  8.模型构建的逐步深入导致重构不可避免,所以提倡柔性设计:设计必须要让人们乐于使用,并且易于做出修改。各种常用柔性设计模式。

  9.如何在复杂系统,多团队下实现模型驱动目标的三大基本原则

  上下文:子模型的边界及转换

  精炼:关注对模型核心的持续提炼

  大比例结构:总指导原则

  《领域驱动设计》读后感(四):《领域驱动设计》书评

  首先说一下我是如何接触这本书的吧。我已经记不起是第一次听说领域驱动是在什么时候了,不过我只记得是在看一本别的架构方面的书时提及到这本书,我顺手在amazon上查了一下,有很多人在推荐这本书。出于对技术的追求,我有立刻把这本书买回家细细研读一下的冲动,于是我上网上书店找了一下,早已经卖断货了,在网上等了好长时间也没有补货上来,在着期间我还几乎走遍了我附近的各个书店,都没有找到。最终我从朋友的朋友那里借到了这本书。

  真正读到后,我暗自庆幸当初苦苦寻觅这本书是一个多么正确的决定,在我现在看来这本书使我在学习对面向对象的路上少走了不少弯路。

  因为是别人的书也就没有来的及读第二遍,现在终于拿到属于自己的书了,我迫不及待的又重读了这本书。

  作者在书的组织上是由浅入深,并兼顾了对非领域模型的讨论,作者不仅仅讨论了自己设计的成功之处,也讨论了在多年的工作中遇到的一系列问题,以及如何用领域驱动的方式去挽救项目。

  我们所开发的软件通常来说都并非是自己熟悉的行业,每个人都不自觉的会用自己的方式去理解软件的一个业务的服务流程。开发人员达成一致的流程往往不是客户真正实用的流程,这种不一致的情况可能会导致开发中反复的修改,更严重的可能会导致整个软件的架构都要发生重大的变化。这样会增加项目的开发时间增加项目的开发成本,如果这些条件不被允许,那么最终也就导致了项目的失败。

  现在的软件开发过程理论都提倡和客户有足够的交流,确保开发出来的软件就是客户真正想要的。

  领域驱动不是过程理论,但是它给出了具体的实践过程,兼顾领域专家和开发人员,两者达成一个共同的讨论模型,基于这个模型,软件设计人员或者开发人员能够根据自己对技术的理解,去设计合理的架构。这本书的作者给出了很多的建议来从模型讨论中提炼合理的架构,设计领域的对象模型,同时给出了一些常用的设计模式如何在领域层中应用的建议,并给出了领域层的边界(分清楚那个层应该干什么如何干,这个很重要)。

  我们每天做的面向对象设计,其实就是在提炼类和划分类的职责。我们喜欢把这个过程称之为设计,如何能更好的的分析和提炼这是一门艺术。

  我们每个人都可以做设计,在做的过程中谈不上这个过程的好坏,只有设计的结果我们才能有好坏之分。比如说我们每个人都可以下厨房做菜,做菜的过程谈不上好坏,但最终菜的味道就有好坏之分了。现实中如果我们想把菜做好,那么找一本厨艺大师的做菜心得的书读一下,一定会比我们瞎摸索要好的多。Eric Evans就是当之无愧领域模型设计界的厨艺大师,我们没有理由自己去瞎摸索来提高自己的“厨艺”。

  【摘自】http://www.cnblogs.com/cuiweifu/archive/2010/12/09/book_review_for_Domain_Driven_Design.html

  《领域驱动设计》读后感(五):OOA面向对象的分析方法-DDD篇

面向过程和面向对象

  前几天在群里和小伙伴们讨论OOA。 有人问:“这是什么?” 答:“面向对象的分析,是一种需求分析方法。” 回:“没听过。”

  后来我想了一下,可能是刚接触IT行业就赶上了java的盛行,没听过也很正常。 记得我上大学的时候,主流还大都是C、VB之类的。 后来竟然发现自己没有办法很好的去解释“面向对象”和“现象过程”的区别。 于是请教了度娘,看到了一个用“五子棋”为例的解释,非常清晰。

例如五子棋,面向过程的设计思路就是首先分析问题的步骤:1、开始游戏,2、黑子先走,3、绘制画面,4、判断输赢,5、轮到白子,6、绘制画面,7、判断输赢,8、返回步骤2,9、输出最后结果。把上面每个步骤用分别的函数来实现,问题就解决了。 而面向对象的设计则是从另外的思路来解决问题。整个五子棋可以分为 1、黑白双方,这两方的行为是一模一样的,2、棋盘系统,负责绘制画面,3、规则系统,负责判定诸如犯规、输赢等。第一类对象(玩家对象)负责接受用户输入,并告知第二类对象(棋盘对象)棋子布局的变化,棋盘对象接收到了棋子的i变化就要负责在屏幕上面显示出这种变化,同时利用第三类对象(规则系统)来对棋局进行判定。

  所以,面向对象的方法讲究的是抽象、对象化。

  对于简单的业务需求,使用哪种方法的差别其实并不大。 但是如果业务需求比较复杂,以后希望有较好的可扩展性,“面向对象”会更加适合。

  而现实是,我们面对的基本上都么啥简单的业务需求。 并且因为未来的不确定性非常大,变化又多又快,现在OO的方法就更加适用了。 作为DEV,会使用OO进行设计和开发。 而作为BA,会使用OO进行分析,简写也就是OOA。

那么我们如何使用OOA呢?

  我们会使用UML这类工具去进行分析,思考,也就基本是在使用OOA了。 关于UML之前说的也比较多,而且市面上的书籍非常多。 感兴趣的可以自行研究下。 今天想分享的是我最近在研究的另外一种分析方法DDD。

DDD与UML

  因为DDD和UML都是OO的,所以如果你对UML比较熟悉,那么理解起来DDD不是那么的困难。 如果你以前写过代码,那么理解起来会更加容易。

  通常我们会用UML进行业务描述,甚至是对象关系的描述。 但是,代码是如何实现的,如果我们的活动图的某个活动扩展或者改变了,会对数据库或者代码产生多大的影响,这些都无从得知。 换句话说,我们的UML模型和代码实现是脱离的。 不错,我们用UML描述了我们产品的业务过程,对象生命周期,对象关系。 但是这些真的只是我们的描述而已。

最近小婧的产品遇到一件比较棘手的事情。 我们的标准化产品给到客户去实施,难免会需要根据客户的业务需求进行二次开发。 基于产品保护的原则,底层代码是不能提供给实施团队进行修改的。 按照道理来说,实施团队只能在我们提供的开放接口以及业务层进行二次开发。 虽然我们也是用OO的方法分析、设计和开发的产品,但是在面临这样的要求是显得很被动。

  这里面的原因有很多,但是根本原因是在分析和设计的时候,并没有把领域层、应用层分离开。 我们把很多的业务规则写在了应用层,导致修改的时候需要动到一些基础的业务规则。

  我们开始研究DDD,发现其实DDD会更适合我们这类大型复杂的产品。

首先,DDD的分层结构让设计更加清晰。

评价:

[匿名评论]登录注册

评论加载中……