领域驱动设计:软件核心复杂性应对之道(修订版) - (EPUB全文下载)
文件大小:0.48 mb。
文件格式:epub 格式。
书籍内容:
领域驱动设计:软件核心复杂性应对之道(修订版)
第一部分 运用领域模型
第1章 消化知识
第2章 交流与语言的使用
第3章 绑定模型和实现
第二部分 模型驱动设计的构造块
第4章 分离领域
第5章 软件中所表示的模型
第6章 领域对象的生命周期
第7章 使用语言:一个扩展的示例
第三部分 通过重构来加深理解
第8章 突破
第9章 将隐式概念转变为显式概念
第10章 柔性设计
第11章 应用分析模式
第12章 将设计模式应用于模型
第13章 通过重构得到更深层的理解
第四部分 战略设计
第14章 保持模型的完整性
第15章 精炼
第16章 大型结构
第17章 领域驱动设计的综合运用
结束语
附录
术语表
参考文献
图片说明
欢迎来到异步社区!
看完了
第一部分 运用领域模型
上面这张图是18世纪中国描绘的世界地图。图中央最大的部分是中国,其周围散布着其他国家,但这些国家只是草草地表示了一下。这是适用于当时中国社会的世界模型,它意在关注中国自身。然而,这幅地图所呈现的世界观对于处理外交事务并无助益。当然,它对现代中国也毫无用处。地图就是模型,而模型被用来描绘人们所关注的现实或想法的某个方面。模型是一种简化。它是对现实的解释——把与解决问题密切相关的方面抽象出来,而忽略无关的细节。
每个软件程序是为了执行用户的某项活动,或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。一些领域涉及物质世界,例如,机票预订程序的领域中包括飞机乘客在内。有些领域则是无形的,例如,会计程序的金融领域。软件领域一般与计算机关系不大,当然也有例外,例如,源代码控制系统的领域就是软件开发本身。
2
为了创建真正能为用户活动所用的软件,开发团队必须运用一整套与这些活动有关的知识体系。所需知识的广度可能令人望而生畏,庞大而复杂的信息也可能超乎想象。模型正是解决此类信息超载问题的工具。模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义,并专注于问题。
领域模型并非某种特殊的图,而是这种图所要传达的思想。它绝不单单是领域专家头脑中的知识,而是对这类知识严格的组织且有选择的抽象。图可以表示和传达一种模型,同样,精心书写的代码或文字也能达到同样的目的。
领域建模并不是要尽可能建立一个符合“现实”的模型。即使是对具体、真实世界中的事物进行建模,所得到的模型也不过是对事物的一种模拟。它也不单单是为了实现某种目的而构造出来的软件机制。建模更像是制作电影——出于某种目的而概括地反映现实。即使是一部纪录片也不会原封不动地展现真实生活。就如同电影制片人讲述故事或阐明观点时,他们会选择素材,并以一种特殊方式将它们呈现给观众,领域建模人员也会依据模型的作用来选择具体的模型。
模型在领域驱动设计中的作用
在领域驱动的设计中,3个基本用途决定了模型的选择。
(1) 模型和设计的核心互相影响。正是模型与实现之间的紧密联系才使模型变得有用,并确保我们在模型中所进行的分析能够转化为最终产品(即一个可运行的程序)。模型与实现之间的这种紧密结合在维护和后续开发期间也会很有用,因为我们可以基于对模型的理解来解释代码。(参见第3章)
3
(2) 模型是团队所有成员使用的通用语言的中枢。由于模型与实现之间的关联,开发人员可以使用该语言来讨论程序。他们可以在无需翻译的情况下与领域专家进行沟通。而且,由于该语言是基于模型的,因此我们可借助自然语言对模型本身进行精化。(参见第2章)
(3) 模型是浓缩的知识。模型是团队一致认同的领域知识的组织方式和重要元素的区分方式。透过我们如何选择术语、分解概念以及将概念联系起来,模型记录了我们看待领域的方式。当开发人员和领域专家在将信息组织为模型时,这一共同的语言(模型)能够促使他们高效地协作。模型与实现之间的紧密结合使来自软件早期版本的经验可以作为反馈应用到建模过程中。(参见第1章)
接下来的3章分别考查上述3种基本用途的意义和价值,以及它们之间的关联方式。遵循这些原则使用模型可以很好地支持具有丰富功能的软件的开发,否则就需要耗费大规模投资进行专门开发。
软件的核心
软件的核心是其为用户解决领域相关的问题的能力。所有其他特性,不管有多么重要,都要服务于这个基本目的。当领域很复杂时,这是一项艰巨的任务,要求高水平技术人员的共同努力。开发人员必须钻研领域以获取业务知识。他们必须磨砺其建模技巧,并精通领域设计。
然而,在大多数软件项目中,这些问题并未引起足够的重视。大部分有才能的开发人员对学习与他们的工作领域有关的知识不感兴趣,更不会下力气去扩展自己的领域建模技巧。技术人员喜欢那些能够提高其技能的可量化问题。领域工作很繁杂,而且要求掌握很多复杂的新知识,而这些新知识看似对提高计算机科学家的能力并无裨益。
4
相反,技术人才更愿意从事精细的框架工作,试图用技术来解决领域问题。他们把学习领域知识和领域建模的工作留给别人去做。软件核心的复杂性需要我们直接去面对和解决,如果不这样做,则可能导致工作重点的偏离。
在一次电视访谈节目中,喜剧演员John Cleese讲述了电影《巨蟒和圣杯》(Monty Python and the Holy Grail)在拍摄期间发生的一个小故事。有一幕他们反复拍了很多次,但就是感觉不够滑稽。最后,他停下来,与另一位喜剧演员Michael Palin(该幕中的另一位演员)商量了一下,他们决定稍微改变一下。随后又拍了一次,终于令他们满意了,于是收工。
第二天早上,Cleese观看了剪辑人员为前一天工作所做的粗剪。到了那个令他们颇费周章的场景时,Cleese发现剪辑人员竟然使用了先前拍摄的一个镜头,影片到这里又变得不滑稽了。
他问剪辑人员为什么没有按要求使用最后拍的那个镜头,剪辑人员回答说:“那个镜头不能用,因为有人闯入了镜头。”Cleese连看了两遍,仍未发现有什么不妥。最后,剪辑人员将影片暂停,并指出在屏幕边缘有一只一闪而过的大衣袖子。
影片的剪辑人员专注于准确完成自 ............
以上为书籍内容预览,如需阅读全文内容请下载EPUB源文件,祝您阅读愉快。
书云 Open E-Library » 领域驱动设计:软件核心复杂性应对之道(修订版) - (EPUB全文下载)