[领域驱动设计]Eric Evans

目 录 封面 其他 扉页 版权 版权声明 译者序 序 前言 致谢 第一部分 运用领域模型 第1章 消化知识 1.1 有效建模的要素 1.2 知识消化 1.3 持续学习 1.4 知识丰富的设计 1.5 深层模型 第2章 交流与语言的使用 2.1 模式：UBIQUITOUS LANGUAGE 2.2 “大声地”建模 2.3 一个团队，一种语言 2.4 文档和图 2.4.1 书面设计文档 2.4.2 完全依赖可执行代码的情况 2.5 解释性模型 第3章 绑定模型和实现 3.1 模式：MODEL-DRIVEN DESIGN 3.2 建模范式和工具支持 3.3 揭示主旨：为什么模型对用户至关重要 3.4 模式：HANDS-ON MODELER 第二部分 模型驱动设计的构造块 第4章 分离领域 4.1 模式：LAYERED ARCHITECTURE 4.1.1 将各层关联起来 4.1.2 架构框架 4.2 领域层是模型的精髓 4.3 模式：THE SMART UI“反模式” 4.4 其他分离方式 第5章 软件中所表示的模型 5.1 关联 5.2 模式：ENTITY（又称为REFERENCE OBJECT） 5.2.1 ENTITY建模 5.2.2 设计标识操作 5.3 模式：VALUE OBJECT 5.3.1 设计VALUE OBJECT 5.3.2 设计包含VALUE OBJECT的关联 5.4 模式：SERVICE 5.4.1 SERVICE与孤立的领域层 5.4.2 粒度 5.4.3 对SERVICE的访问 5.5 模式：ＭODULE（也称为PACKAGE） 5.5.1 敏捷的MODULE 5.5.2 通过基础设施打包时存在的隐患 5.6 建模范式 5.6.1 对象范式流行的原因 5.6.2 对象世界中的非对象 5.6.3 在混合范式中坚持使用MODEL-DRIVEN DESIGN 第6章 领域对象的生命周期 6.1 模式：AGGREGATE 6.2 模式：FACTORY 6.2.1 选择FACTORY及其应用位置 6.2.2 有些情况下只需使用构造函数 6.2.3 接口的设计 6.2.4 固定规则的相关逻辑应放置在哪里 6.2.5 ENTITY FACTORY与VALUE OBJECT FACTORY 6.2.6 重建已存储的对象 6.3 模式：REPOSITORY 6.3.1 REPOSITORY的查询 6.3.2 客户代码可以忽略REPOSITORY的实现，但开发人员不能忽略 6.3.3 REPOSITORY的实现 6.3.4 在框架内工作......