两本免费DDD电子书籍

一个是INFQ的领域驱动设计精简版DDD Quickly，这个可能不少人已经知道。

还有一本DDD – Step by Step(链接已经失效)

目录结构大概如下：
1.通用语言
2.有界上下文(Bounded Contexts)
3.没有数据库There Is No Database: 该段说明DDD是和数据库对立的，如果首先从数据库开始，那就是数据库驱动的设计(不是领域模型驱动的设计了)。我们会自觉或不自觉地数据库元素映射到领域中(这是和DDD相反的，也是很多人误用Hibernate根本原因所在)，那么我们的数据库元素有可能损害我们的域模型，迫使领域模型纯粹成为持久层的一个技术选择(DTO和VO有时就是数据库强奸对象的结果)。
4.Entities实体和值对象
5.聚合和聚合根Aggregates and Aggregate Roots
6.Services服务
7.DDD适合什么系统?
8.仓储模式The Repository Pattern
9.Living In The Enterprise
10.规格模式The Specification Pattern
11.验证，一致性和不变性Validation, Consistency and Immutability

这本书主要是作者的经验心得总汇，是DDD的精神和主要部分。

上面链接已经失效，推荐另外开源文档：https://github.com/mspnp/cqrs-journey-doc

2012年3月补充：我写的领域驱动设计免费PPT文档

[该贴被admin于2012-03-10 09:54修改过]

希望以后推荐多些ddd的资料给我们这些初学者啊

感谢banq，感谢Jdon~
~学习中~

英文障碍啊，怎么办。看得只想睡觉呢。banq大师，有什么办法练习English？

一定要看看

在电子书籍Domain Driven Design - Step by Step 书中谈到 Command
Query Separation(CQS)模式，命令和查询分离模式。

CQS其实是对类的方法行为范围进行了界定，方法或者可以是一个事件入口，是对某个外部命令事件的响应；或者也可以说是一个能够获得结果数据的查询，但不可以两者都是。

其实使用DBC模式对方法也能够进行约束，这个方法的前置条件是什么？后置条件得到结果预期是什么，这些都以一种合约形式进行约定。

提出CQS是为了解决报表输出问题，报表Reporting常常直接从数据库获得比较自然，排序等，所以，通过CQS模式进行分类，Domain操作属于Command，是从Repository中获得；而Reporting属于查询Query操作，属于传统数据库风格形式。

带来问题是两种场景下数据的同步，个人以为通过缓存可以实现。积极面对不一致性，有时业务不一定要求那么及时，如果要求及时就手工同步。

电子书籍Domain Driven Design - Step by Step 书中谈到领域服务Domain Service定义:
如果实体和值对象是领域中的 “things”东西, 服务则与 actions, operations 和 activities活动有关。(四色原型中也有绿色thing, 橙色的MI，好像有些对应，但不绝对)

不是将所有逻辑都放入实体，这样会让实体显得非常臃肿。
外部客户端通过调用服务，将服务将事件入口，由服务再驱动组织众多实体，为实现某一服务目标努力。

书中举例，购物车要计算购物总数总价，这个功能不适合放在Shoppingcart这个实体中，有PricingService and ShippingCostingService完成，因为这可能需要和其他服务进行交互，特别是计价，以后涉及到打折等等复杂逻辑，放在PriceService中比较好。

区别于贫血模型，服务并不是将实体值对象所有行为方法都拿出来。(这个我在以前帖子里也重复声明过)
[该贴被banq于2009-09-09 17:59修改过]

Unshackle Your Domain
中谈到了不少DDD新观点，比如不应该忽视State，状态，将状态拉进我们的领域;DTO与DOMAIN。

就是老外谈话不能听懂，如果有PPT就能详细了解。

banq常说的四色原型具体指什么，有资料么，想了解一下

Domain Driven Design - Step by Step

网址打不开。。。谁有的话能传一本吗？

lost_alien@qq.com

谢谢！