摘自：dax.net陈晴阳博客
1.NLayerApp是经典的DDD架构
2.关注点分离：分离关注点使得解决特定领域问题的代码从业务逻辑中独立出来，业务逻辑的代码中不再含有针对特定领域问题代码的调用。
3.仓储不是Data Object，也不仅仅是进行数据库CRUD操作的Data Manager，它承担了解耦领域模型和技术架构的重要职责。
4.依赖注入是维持领域模型纯净度的一大利器；另一大利器是领域事件..net中微软有一个轻量级的IoC框架Unity，支持构造器注入，属性注入.IOC作用:将各层的对象以松耦合的方式组织在一起，解耦，各层对象的调用完全面向接口。当系统重构的时候，代码的改写量将大大减少。通常有调用者来创建被调用者的实例。创建被调用者的实例的工作由IOC容器来完成，然后注入调用者，因此也称为依赖注入。
5.领域层：包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型（Domain Model）。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。表现层与应用层之间是通过DTO进行交互的，DTO是没有行为的POCO对象，目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样做会直接将领域对象的行为暴露给表现层
6.Specification是值对象，它是领域层的一部分，同样也不会去关心持久化技术实现细节。规约是一种布尔断言，它表述了给定的对象是否满足当前约定的语义。
摘自：netfocus汤雪华博客
1.聚合是由实体和值对象组成，一个聚合有一个聚合根，聚合根是实体，并且是只读的实体，因为聚合的子实体是可以被临时传递到外部的，绕过聚合根修改了聚合内的东西，这样就无法确保聚合内的不变性了，我们要避免任何可能从外部修改聚合的行为发生，所有修改聚合的行为必须通过聚合根来实现。
2.聚合有不变性约束规则。
3.聚合的两条推荐准则：聚合不要设计的过大，过大的聚合很难确保不变性，从而很难确保数据的强一致性；聚合与聚合之间不要通过引用的方式来关联，而应该通过ID关联。
4.聚合内的非根的Entity以及Value Object之间不要相互引用，聚合内的所有Child可以对聚合根持有引用，如果一个子实体需要和另外一个子实体交互，则应该通过聚合根完成。
5.仓储应理解为一个在内存中维护一系列聚合根的集合，一个聚合根配备一个仓储。
6.仓储提供的接口应该总是接受聚合根或返回聚合根，不能返回聚合内的其他Entity或Value Object。
7.仓储提供的所有接口应该仅为领域模型使用；基本的仓储接口只需要三个：Add，Remove，GetById，其他可由业务需要而定。
8.如果一个操作仅由一个聚合根就可以完成，那么直接调用该聚合根完成即可
9.领域服务依赖仓储时，工厂依赖于领域服务或仓储时，都应该采用构造函数注入的方式，这样可以避免领域模型中不会出现DependencyResolver.Resolve<T>()这样的语句。
10.领域对象是拥有行为的，但要合理而自然。
11.不要因为领域服务的引入让聚合根变得贫血，聚合根应该有的职责还是必须要由聚合根来承担。
12.如果基于贫血模型的开发，那么软件只是一个帮助人类记录事实的工具
13.领域模型对象分为实体、值对象和服务
14.EF目前不支持聚合概念，所有的实体都被一股脑地塞进ObjectContext对象的EntitySet 属性当中，不过这没关系，接下来的文章我会介绍如何在EF中引入聚合的概念