精品下载站:打造最安全最新的免费软件下载站! 全站导航最近更新

首页pdf文件互联网/科技 → 领域驱动设计软件核心复杂性应对之道PDF 高清完整版

领域驱动设计软件核心复杂性应对之道PDF高清完整版

  • 授权方式:免费软件
  • 软件类型:国产软件
  • 软件来源:暂无
  • 更新时间:2021-02-22
  • 官方网址:暂无
  • 软件大小:20.8M
  • 推荐星级:
  • 运行环境:WinAll

软件介绍 软件截图 相关下载 相关文章 点击评论

软件标签: 领域驱动设计软件

领域驱动设计软件核心复杂性应对之道PDF

全书围绕着设计和开发实践,结合若干真实的项目案例,向读者阐述如何在真实的软件开发中应用领域驱动设计,小编今天给大家带来了领域驱动设计软件核心复杂性应对之道PDF书籍,可以免费下载哦.

编辑推荐

●“领域驱动设计之父”经典著作●众多声名显赫软件大师鼎力推荐●凝聚领域建模专家数十年的实战经验●深度剖析构建高质量复杂系统的核心技术领域模型使开发人员可以表达丰富的软件功能需求,

由此实现的软件可以满足用户真正的需要,因此被公认为是软件设计的关键所在,其重要性显而易见。但讲述如何将领域模型用于软件开发过程的杰出的实用资料却不多见。本书正是这一领域声名显赫的作品,

受到众多业界大师的赞美和推介,广受读者好评。要通过创建领域模型来加速复杂的软件开发,就需要利用大量实践和标准模式在开发团队中形成统一的交流语言;不但要重构代码,而且要重构代码底层的模型;

同时采取反复迭代的敏捷开发方法,深入理解领域特点,促进领域专家与程序员的良好沟通。针对这些内容,本书结合真实项目,系统地介绍了领域驱动开发的目标、意义和方法,充分讨论了复杂系统的建模与设计问题。

本书将指导面向对象开发人员、系统分析人员和设计人员合理地组织工作,各有侧重、彼此协作,有条不紊地进行复杂系统的开发,帮助他们建立丰富而实用的领域模型,并由此创建长期适用的优质软件。

相关内容部分预览

内容简介

本书是领域驱动设计方面的经典之作,修订版更是对之前出版的中文版进行了全面的修订和完善。全书围绕着设计和开发实践,结合若干真实的项目案例,向读者阐述如何在真实的软件开发中应用领域驱动设计。

书中给出了领域驱动设计的系统化方法,并将人们普遍接受的一些实践综合到一起,融入了作者的见解和经验,展现了一些可扩展的设计新实践、已验证过的技术以及便于应对复杂领域的软件项目开发的基本原则。

作者简介

Eric Evans “领域驱动设计之父”,世界杰出软件建模专家。他创建了Domain Language公司,致力于帮助公司机构创建与业务紧密相关的软件。他在世界各地宣讲领域驱动设计(Domain-Driven Design,DDD)的思想,

开设课程,参加会议,接受专访,拥有大批的追随者。从20世纪80年代开始,他就以设计师和程序员的双重身份参与过许多大型面向对象系统的设计和开发,涉及各种复杂的业务和技术领域。同时,他还培训和指导过许多开发团队开展极限编程实践。

目 录

第一部分 运用领域模型

第1章 消化知识 5

1.1 有效建模的要素 9

1.2 知识消化 10

1.3 持续学习 11

1.4 知识丰富的设计 12

1.5 深层模型 15

第2章 交流与语言的使用 16

2.1 模式:UBIQUITOUS LANGUAGE 16

2.2 “大声地”建模 21

2.3 一个团队,一种语言 22

2.4 文档和图 24

2.4.1 书面设计文档 25

2.4.2 完全依赖可执行代码的情况 27

2.5 解释性模型 27

第3章 绑定模型和实现 29

3.1 模式:MODEL-DRIVEN DESIGN 30

3.2 建模范式和工具支持 32

3.3 揭示主旨:为什么模型对用户至关重要 38

3.4 模式:HANDS-ON MODELER 39

第二部分 模型驱动设计的构造块

第4章 分离领域 43

4.1 模式:LAYERED ARCHITECTURE 43

4.1.1 将各层关联起来 46

4.1.2 架构框架 47

4.2 领域层是模型的精髓 48

4.3 模式:THE SMART UI“反模式” 48

4.4 其他分离方式 50

第5章 软件中所表示的模型 51

5.1 关联 52

5.2 模式:ENTITY(又称为REFERENCE OBJECT) 56

5.2.1 ENTITY建模 59

5.2.2 设计标识操作 60

5.3 模式:VALUE OBJECT 62

5.3.1 设计VALUE OBJECT 64

5.3.2 设计包含VALUE OBJECT的关联 67

5.4 模式:SERVICE 67

5.4.1 SERVICE与孤立的领域层 69

5.4.2 粒度 70

5.4.3 对SERVICE的访问 70

5.5 模式:MODULE(也称为PACKAGE) 71

5.5.1 敏捷的MODULE 72

5.5.2 通过基础设施打包时存在的隐患 73

5.6 建模范式 75

5.6.1 对象范式流行的原因 76

5.6.2 对象世界中的非对象 77

5.6.3 在混合范式中坚持使用MODEL-DRIVEN DESIGN 78

第6章 领域对象的生命周期 80

6.1 模式:AGGREGATE 81

6.2 模

书籍读后感

《领域驱动设计》一书是领域模型领域的代表作,被很多牛人推荐,其中的概念还需要在思考和实践中逐步理解。书中描述的一些现象有些与我们类似,比如越来越多的领域规则被嵌入到查询代码中,或者直接就不见了。领域逻辑跑到查询代码和客户代码中去了,而实体和值对象变成了纯粹的数据容器。大部分数据访问基础结构的技术复杂性,很快使得客户代码陷入混乱,最终开发人员只好抛弃领域层,把模型变成一个摆设。以下将针对一些非技术问题进行一些记录,方便以后查阅思考。

* 如果程序员对领域较为熟悉,他们便可以使得软件保持能够继续扩展的良好状态,但是如果程序员对于该领域不敢兴趣,他们知道应用程序应该做什么,却不了解其背后的原理。这样做虽然能够建立一个有用的软件,但是项目永远不会具有能够从前期特征能推导出更加强大的新特征的能力。

* 领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点,它很适合作为这种通用语言的构造基础。

* 很多原因都会造成软件开发的复杂性,然而其核心则是由于问题领域本身的复杂性。控制复杂问题的关键是建立一个好的领域模型,它越过问题域的表象介绍其底层的结构,给软件开发人员提供所需的方法。

* 模型驱动设计不仅要求我们的设计能够将概念表达出来,还应该能够被高效的实现。一个领域模式不仅仅是用UML图表达出来的优雅的想法,它还应该为模型驱动设计中的某个编程问题提供解决方案。当我们的模型应该恰当时,我们就可以深入下去,挖掘出一整套解决某种领域建模问题的思路。而且,这种寻找高效实现的经验的不断积累,也能使我们受益匪浅。

* 软件的最终目的是为用户提供服务,但是,它首先必须为开发人员服务。如果软件的行为非常复杂,但是又缺乏良好的设计,那它就会变得难以重构和组合。由于开发人员不能够确切的预知计算的全部内涵,重复问题就产生了。如果设计元素都是整块的、无法重新组合的部分,重复就是不可避免的了。我们可以对那些类和方法进行分解使之便于重用,但这样一来各个小部分分别有什么作用又变得难以跟踪了。一个缺乏清晰设计的软件,单是看到其中的混乱结构就会让开发人员头脑发晕,更不用说对设计进行修改(那只会使设计更加混乱),有时甚至会由于意料之外的依赖关系而导致设计完全无法工作。这种脆弱性导致我们无法构造出行为更加丰富的系统(除非系统的规模相当小),也阻碍了重构和迭代精化的进行。

* 随着项目开发的进行,我们应该感到速度越来越快,而不是感到包袱越来越层沉。这就要求我们的设计能让人乐于使用,也能很容易的适应改变。这就是柔性设计。

* 模型的选择取决于3个基本的用途: 模型与设计核心的相互塑形、模型是所有团队成员所使用语言的核心、模型用来提炼知识

* 知识消化并不是一个孤立的活动,它是由开发团队与领域专家共同合作,由开发人员领导的。知识消化过程必须探索模型选项,并将它们精化为使用的软件元素。

* 那些没有领域模型,只是靠编写代码来完成一个又一个功能的项目,不能获得知识消化与交流带来的益处。

* 领域模型的不断精化使得开发人员不断地学习他们的重要业务原理,而不是机械的产生新的功能。

* 模型关注的是需求分析,它与编程和设计相互影响。

* 重组会打散团队,知识也会再次分散。仅仅交付了代码而没有传递知识的工作方式使得一些关键的子系统无据可依。使用典型的设计方法时,代码和文档都不能用有效的方式表达出人们辛苦得到的知识,因此当这种口头上的惯例由于任何原因被打破时,知识也就遗失了。

* 高效率的团队依靠学习,有意识的增长自己的知识,这意味着提高技术知识以及一般的领域建模技能,也包括学习所从事的特定领域。

* 使用术语及关系来反映领域的内涵。基于模型的交流提高编写文档的实用性。

* 要将模型作为语言的骨干。使用了通用语言,模型就不仅仅是一个设计工作了。它整合到开发人员与领域专家所做的每一件事中。

* 一定要记住模型并不是图,图的目的是帮助表达和解释模型。

* 说明性模型的图形带有它所表示模型的自然语言解释。一起查看两种图形(说明性模型和类图模型)要比单独查看任何一种更容易理解。

* 一个缺乏设计基础概念的软件最多只能是一个能够做游泳的事情却不能清楚解释它的行为的机械装置。

* 建模与编程的完全分离是不可行的。

* 纯粹的分析模型甚至不能够达到其理解领域的主要目标,因为重要的发现往往出现在设计/实现过程中。模型驱动设计抛弃了分裂分析模型与设计的做法,而是寻找一个单独的模型来满足着两方面的要求。

* 将分析、建模、设计和编码的职责完全隔离起来,会阻碍模型驱动设计。分开会造成:交接时遗漏了模型的一些意图;模型与实现和技术之间的相互作用个所得到的反馈过于间接。

* 负责建模的技术人员必须花时间接触代码,而不论他是否在项目中担当主要角色。任何负责代码修改的人员都必须学习通过代码表达模型。每个开发人员都必须参与一些级别的模型讨论中,并与领域专家接触。

* 解决来自领域方面的软件部分通常只占整个软件系统的一小部分,这与它的重要性相比是不成比例的。我们需要把领域对象跟系统的其他功能分离出来,才能够避免将领域概念与其他软件技术相关的概念混淆或者在系统的庞大中失去了对领域的把握。

* 是领域层而不是应用层负责提供基本的规则。

* 在应用一个框架是,开发团队应该首先明确它的目标:创建一个实现来表示一个领域模型并且用这个实现来解决重要的问题。

* 不受限制的数据库查询实际上会破坏领域对象和聚合的封装。

* 一般来说,不要与框架对着干。寻找合适的方法来保持领域驱动设计的基本方向。如果框架与设计发生矛盾的话,在一些细节问题上顺其自然。寻找领域驱动设计的概念与框架概念有哪些相近之处。当然,这里的假设是我们除了使用该框架之外别无选择。

* 建模和设计不是一个匀速向前的过程,如果不频繁重构,利用新的理解来改进模型和设计,我们就会逐渐变的寸步难行。

* 约束构成了模型概念中特别重要的一种类型。

* 流程是应该被显示的描述出来还是应该隐藏起来?区分的要点很简单:这个流程是领域专家所谈论的流程,还是仅仅是计算机程序机制的一部分?

领域驱动设计软件核心复杂性应对之道PDF截图

领域驱动设计软件核心复杂性应对之道PDF截图0
领域驱动设计软件核心复杂性应对之道PDF截图1
领域驱动设计软件核心复杂性应对之道PDF截图2
领域驱动设计软件核心复杂性应对之道PDF截图3

相关文章

下载地址

点击评论

热门评论
最新评论
昵称:
表情: 高兴 可 汗 我不要 害羞 好 下下下 送花 屎 亲亲
字数: 0/500 (您的评论需要经过审核才能显示)

软件TOP榜