kindle电子书

资源下载,尽在我的书库!
首页 > kindle电子书库 > 工业|计算机|互联网 > 电子、计算机、网络

领域驱动设计:软件核心复杂性应对之道(修订版)(异步图书)

  • 作者: 多作者
  • 体积:15.25 MB
  • 语言:中文
  • 日期:2018-05-03
  • 推荐:

简介:本书是领域驱动设计方面的经典之作,修订版更是对之前出版的中文版进行了全面的修订和完善。

电子书详细介绍

 本书是领域驱动设计方面的经典之作,修订版更是对之前出版的中文版进行了全面的修订和完善。

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

编辑推荐

 

● “领域驱动设计之父”经典著作 
● 众多声名显赫软件大师鼎力推荐 
● 凝聚领域建模专家数十年的实战经验 
● 深度剖析构建高质量复杂系统的核心技术 
领域模型使开发人员可以表达丰富的软件功能需求,由此实现的软件可以满足用户真正的需要,因此被公认为是软件设计的关键所在,其重要性显而易见。但讲述如何将领域模型用于软件开发过程的杰出的实用资料却不多见。本书正是这一领域声名显赫的作品,受到众多业界大师的赞美和推介,广受读者好评。 

要通过创建领域模型来加速复杂的软件开发,就需要利用大量实践和标准模式在开发团队中形成统一的交流语言;不但要重构代码,而且要重构代码底层的模型;同时采取反复迭代的敏捷开发方法,深入理解领域特点,促进领域专家与程序员的良好沟通。针对这些内容,本书结合真实项目,系统地介绍了领域驱动开发的目标、意义和方法,充分讨论了复杂系统的建模与设计问题。 

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

作者简介

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 LANGUAGE16 
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 DESIGN30 
3.2建模范式和工具支持32 
3.3揭示主旨:为什么模型对用户至关重要38 
3.4模式:HANDS—ON MODELER39 
第二部分模型驱动设计的构造块 
第4章分离领域43 
4.1模式:LAYERED ARCHITECTURE43 
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.1ENTITY建模59 
5.2.2设计标识操作60 
5.3模式:VALUE OBJECT62 
5.3.1设计VALUE OBJECT64 
5.3.2设计包含VALUE OBJECT的关联67 
5.4模式:SERVICE67 
5.4.1SERVICE与孤立的领域层69 
5.4.2粒度70 
5.4.3对SERVICE的访问70 
5.5模式:MODULE(也称为PACKAGE)71 
5.5.1敏捷的MODULE72 
5.5.2通过基础设施打包时存在的隐患73 
5.6建模范式75 
5.6.1对象范式流行的原因76 
5.6.2对象世界中的非对象77 
5.6.3在混合范式中坚持使用MODEL—DRIVEN DESIGN78 
第6章领域对象的生命周期80 
6.1模式:AGGREGATE81 
6.2模式:FACTORY89 
6.2.1选择FACTORY及其应用位置91 
6.2.2有些情况下只需使用构造函数93 
6.2.3接口的设计94 
6.2.4固定规则的相关逻辑应放置在哪里94 
6.2.5ENTITY FACTORY与VALUEOBJECT FACTORY95 
6.2.6重建已存储的对象95 
6.3模式:REPOSITORY97 
6.3.1REPOSITORY的查询101 
6.3.2客户代码可以忽略REPOSITORY的实现,但开发人员不能忽略102 
6.3.3REPOSITORY的实现103 
6.3.4在框架内工作104 
6.3.5REPOSITORY与FACTORY的关系104 
6.4为关系数据库设计对象106 
第7章使用语言:一个扩展的示例108 
7.1货物运输系统简介108 
7.2隔离领域:引入应用层110 
7.3将ENTITY和VALUE OBJECT区别开110 
7.4设计运输领域中的关联112 
7.5AGGREGATE边界113 
7.6选择REPOSITORY113 
7.7场景走查115 
7.7.1应用程序特性举例:更改Cargo的目的地115 
7.7.2应用程序特性举例:重复业务116 
7.8对象的创建116 
7.8.1Cargo的FACTORY和构造函数116 
7.8.2添加Handling Event117 
7.9停一下,重构:Cargo AGGREGATE的另一种设计118 
7.10运输模型中的MODULE120 
7.11引入新特性:配额检查122 
7.11.1连接两个系统123 
7.11.2进一步完善模型:划分业务124 
7.11.3性能优化125 
7.12小结126 
第三部分通过重构来加深理解 
第8章突破131 
8.1一个关于突破的故事131 
8.1.1华而不实的模型132 
8.1.2突破133 
8.1.3更深层模型135 
8.1.4冷静决策137 
8.1.5成果138 
8.2机遇138 
8.3关注根本138 
8.4后记:越来越多的新理解139 
第9章将隐式概念转变为显式概念140 
9.1概念挖掘140 
9.1.1倾听语言140 
9.1.2检查不足之处144 
9.1.3思考矛盾之处148 
9.1.4查阅书籍148 
9.1.5尝试,再尝试150 
9.2如何为那些不太明显的概念建模150 
9.2.1显式的约束151 
9.2.2将过程建模为领域对象153 
9.2.3模式:SPECIFICATION154 
9.2.4SPECIFICATION的应用和实现156 
第10章柔性设计168 
10.1模式:INTENTION—REVEALING INTERFACES169 
10.2模式:SIDE—EFFECT—FREE FUNCTION173 
10.3模式:ASSERTION177 
10.4模式:CONCEPTUAL CONTOUR181 
10.5模式:STANDALONE CLASS184 
10.6模式:CLOSURE OF OPERATION186 
10.7声明式设计188 
10.8声明式设计风格190 
10.9切入问题的角度197 
10.9.1分割子领域197 
10.9.2尽可能利用已有的形式198 
第11章应用分析模式206 
第12章将设计模式应用于模型217 
12.1模式:STRATEGY(也称为POLICY)218 
12.2模式:COMPOSITE221 
12.3为什么没有介绍FLYWEIGHT226 
第13章通过重构得到更深层的理解227 
13.1开始重构227 
13.2探索团队227 
13.3借鉴先前的经验228 
13.4针对开发人员的设计229 
13.5重构的时机229 
13.6危机就是机遇230 
第四部分战略设计 
第14章保持模型的完整性233 
14.1模式:BOUNDED CONTEXT235 
14.2模式:CONTINUOUS INTEGRATION239 
14.3模式:CONTEXT MAP241 
14.3.1测试CONTEXT的边界247 
14.3.2CONTEXT MAP的组织和文档化247 
14.4BOUNDED CONTEXT之间的关系248 
14.5模式:SHARED KERNEL248 
14.6模式:CUSTOMER/SUPPLIER DEVELOPMENT TEAM250 
14.7模式:CONFORMIST253 
14.8模式:ANTICORRUPTION LAYER255 
14.8.1设计ANTICORRUPTION LAYER的接口256 
14.8.2实现ANTICORRUPTION LAYER256 
14.8.3一个关于防御的故事259 
14.9模式:SEPARATE WAY260 
14.10模式:OPENHOST SERVICE261 
14.11模式:PUBLISHED LANGUAGE262 
14.12“大象”的统一264 
14.13选择你的模型上下文策略267 
14.13.1团队决策或更高层决策268 
14.13.2置身上下文中268 
14.13.3转换边界268 
14.13.4接受那些我们无法更改的事物:描述外部系统269 
14.13.5与外部系统的关系269 
14.13.6设计中的系统270 
14.13.7用不同模型满足特殊需要270 
14.13.8部署271 
14.13.9权衡271 
14.13.10当项目正在进行时272 
14.14转换272 
14.14.1合并CONTEXT:SEPARATE WAY→SHARED KERNEL273 
14.14.2合并CONTEXT:SHARED KERNEL→CONTINUOUS INTEGRATION274 
14.14.3逐步淘汰遗留系统275 
14.14.4OPEN HOST SERVICE→PUBLISHED LANGUAGE276 
第15章精炼277 
15.1模式:CORE DOMAIN278 
15.1.1选择核心280 
15.1.2工作的分配280 
15.2精炼的逐步提升281 
15.3模式:GENERIC SUBDOMAIN282 
15.3.1通用不等于可重用286 
15.3.2项目风险管理287 
15.4模式:DOMAIN VISION STATEMENT287 
15.5模式:HIGHLIGHTED CORE289 
15.5.1精炼文档289 
15.5.2标明CORE290 
15.5.3把精炼文档作为过程工具291 
15.6模式:COHESIVE MECHANISM292 
15.6.1GENERIC SUBDOMAIN与COHESIVE MECHANISM的比较293 
15.6.2MECHANISM是COREDOMAIN一部分294 
15.7通过精炼得到声明式风格294 
15.8模式:SEGREGATED CORE295 
15.8.1创建SEGREGATED CORE的代价296 
15.8.2不断发展演变的团队决策296 
15.9模式:ABSTRACT CORE301 
15.10深层模型精炼302 
15.11选择重构目标302 
第16章大型结构303 
16.1模式:EVOLVING ORDER306 
16.2模式:SYSTEM METAPHOR308 
16.3模式:RESPONSIBI LITYLAYER309 
16.4模式:KNOWLEDGE LEVEL321 
16.5模式:PLUGGABLE COMPONENT FRAMEWORK328 
16.6结构应该有一种什么样的约束332 
16.7通过重构得到更适当的结构333 
16.7.1最小化333 
16.7.2沟通和自律334 
16.7.3通过重构得到柔性设计334 
16.7.4通过精炼可以减轻负担334 
第17章领域驱动设计的综合运用336 
17.1把大型结构与BOUNDED CONTEXT结合起来使用336 
17.2将大型结构与精炼结合起来使用339 
17.3首先评估339 
17.4由谁制定策略341 
17.4.1从应用程序开发自动得出的结构341 
17.4.2以客户为中心的架构团队341 
17.5制定战略设计决策的6个要点342 
17.5.1技术框架同样如此344 
17.5.2注意总体规划345 
结束语 
附录351 
术语表354 
参考文献357 
图片说明359 
索引360

我来说两句

本书评论

共有 0 条评论
图书分类
我的书库手机端
帮助中心
会员登录 ×
新用户注册 ×