One interesting DDD rule is: you should create repositories only for aggregate roots. 
When I read about it the first time I interpreted it this way: create repositories at least for all aggregate roots, but when you need a little repository for something else go ahead and implement it (and nobody will know what you did). 
So I was thinking that the rule is somehow flexible. It turns out that it‘s not, and this is good: it keeps the domain stable and coherent. If entity A is an aggregate root, entity B is part of that aggregate, and you need to load B separated from the concept of A, this is a sign that the implementation does not reflect the business needs (anymore). In this case, B should probably become the root of its own aggregate

Re:实体框架之领域驱动实践（七）

[ 2010-2-2 14:00:00 | By: Webcopy(游客) ]

这里的 IRepository接口被where子句限定为EF中的EntityObject,这就与EF框架紧耦合了.
个人觉得IResository接口定义应该是在领域模型中,不应该与具体的框架或类库关联.试想,如果我用NHibernate对 IResository接口进行实现,就与EF无关了.
也许我理解的不正确.....

以下为blog主人的回复：
我个人的意见还是具体问题具体分析。NHibernate是不需要实体类去继承任何类或者实现任何接口的，因此，在这里将IRepository的泛型类型约束为EntityObject也无妨。换句话说，即使你的类继承了EntityObject，NHibernate照样可以帮你完成持久化等操作。但如果你所挑选的ORM不是NHibernate，那就视情况而定了。你完全可以定义一个IEntity的接口并将其用作泛型约束。由于C#的单类多接口继承的特性，多出一个IEntity的接口并不会对你的设计造成任何影响。
你考虑问题的思路是正确的，至少你考虑到了框架的扩展性。当然，在实际中，这些基础结构的技术框架是很少变动的，也就是说，一旦选用了EF，就不太可能在今后的系统生命周期中再去换其它的ORM，除非是有特定的需求。在接下来的两篇博文中，我将介绍基于EF的仓储实现方式，以及一种与EF无关的通用仓储框架，在这两篇文章中，你还将体会到依赖注入带给我们的机遇。
（顺便BS下自己，最近太忙了，一直没有机会更新博客，但我一定会将本系列文章写完，敬请期待！）

Re:实体框架之领域驱动实践（七）

[ 2010-2-11 11:07:00 | By: haojie77 ]

Concrete Repository一般都定义在Infrastructure层, 而EF为我们生成的Entity Model又在Domain层, Domain依赖于Infrastucture, 这样一来Concrete Repository是不是也要依赖于Domain中的Entity Model 来生成entity? 这样的双向依赖在.Net中貌似不行. 当我们需要得到一个符合某些特定条件的聚合根集合的时候(比如要显示所有在中国并且姓"郑"的Customer), 那么CustomerRepository.FindBySpec(spec)中如何得到在Domain中定义的Customer? 如果在FindBySpec中只用根据spec拼接出来的sql那就没有这个问题. 换种说法就是 CustomerRepository.FindBySpec的返回类型如果是List<Customer>而不是 List<EntityObject>, Customer又由EF生成在Domain层中, 那么如何解决这个问题? 还是说把CustomerRepository也定义在Domain层中?(我看到您的StoreDDD貌似就是这个意思 Domain.Repositories) 因为那时你用的是ActiveRecord实现的, "有违反DDD经验的嫌疑"是否就是指把Repository定义在了Domain中? 现在如果用EF是否有办法能解决这个问题? 
我甚至想过把EF自动生成的EntityObject当作DTO放在Infrastructure中, 而自己在Domain层中去定义真正的Entity去继承(或者是内聚更合理)EntityObject, 再给与它行为. 但是DDD中说Repository是用来唤醒Entity的, 这么做只能是拿到一个静态的DTO仍旧需要在Domain的Service中去构建 ConcreteEntity(ConcreteEntityObject), 一样有违反DDD经验的嫌疑(Entity并不是由Repository得到). 这只是我随意想到的, 可能思路已经不对了.

以下为blog主人的回复：
你的问题非常有价值。首先应该认识到产生依赖的根源，就是你把Concrete Repository也当做是整个系统架构的一个部分。然而事实是，Concrete Repository是一个可替代组件。要解决你的问题，你需要引入三件事情：接口、泛型以及依赖注入。
首先，将Repository的接口定义在领域层，接口采用泛型定义，也就是类似我在本文中的定义方式。注意：在领域层里的仅仅是一个接口而已，它跟技术架构没有任何关系，就像领域事件（Domain Events）一样，将一切与技术架构相关的具体实现委托给Concrete Repository，这样仍然能够保持领域模型的纯净度；其次，在定义Concrete Repository的Assembly上直接引用Domain Model，这样做是合理的，因为Concrete Repository不是系统架构中的一部分，而仅仅是一个可替换的组件，因此其实现方式是可以任意的，不会影响整个系统架构；再次，使用依赖注入，将 Concrete Repository注入到Domain Model中，至此，Domain Model一直是在使用Repository的接口，而没有关心这个接口的背后是否是Concrete Repository，当然，在你的Concrete Repository中也可以使用规约模式对对象进行筛选和验证。常用的依赖注入框架有Spring.NET和Castle Windsor。
根据你的提问，我临时开发了一个Sample，下载地址是：http://www.sunnychen.org/attachments /RepositoryStorm.rar。通过这个例子，你可以看到一个非常纯净的领域模型。

Re:实体框架之领域驱动实践（七）

[ 2010-2-11 12:55:00 | By: haojie77 ]

关于我说的把EF生成的 EntityObject放入Infrastructure中, 代码上貌似还是可以实现. Entity Data Model 从名字上看,微软本身对其的定义还是基于数据的. 所以我才想到把EF生成的Entity当做DTO, 这样很多情况下也不用另外构建DTO,直接用EntityObject就可以了. 这里可能扯得有点远了, 也许我这个想法本身有不少疏漏和错误. 在这里希望能学习到各方面的知识:) 
namespace DomainModel.Model
{
class Customer : RealEntity
{
public Customer(EntityObject eObject) : base(eObject)
{ 
}
}
}
namsapce Infrasturcture.DomainBase
{
public abstract class RealEntity
{
private EntityObject _EntityObject;
public RealEntity(EntityObject eObject)
{
_EntityObject = eObject;
}
}
}
namespace Infrasturcture.Repositories
{
class CustomerRespository<T> : IRepository<T> where T : RealEntity
{
public T FindBy(object key) 
{
EntityObject eObject = null;// Use linq to entity to get it
return Activator.CreateInstance(typeof(T), eObject) as T;
}
}
}

以下为blog主人的回复：
你有这方面的考虑是很好的。我只能说是Microsoft对Entity的定义使你在理解上产生了偏差。如我前面的文章所述，EF最大的一个缺点就是不支持实体行为，即使有，也是硬生生地从SQL Stored Procedure来产生的，但这不能成为实体行为。于是，在EF中，Entity就成了充斥着getter/setter的数据对象了，也就是DDD所提到的贫血模型。
从我个人的角度，我仍然会将EntityObject放在领域层，这样就不需要你定义的那个RealEntity类；EntityObject是要有行为的，才能参与领域活动，如何使其具有行为？我的解决方案在前文也有讲述：使用C#的partial关键字。
通常情况下，DTO是用来在层与层之间交换数据用的，在DDD中属于值对象，你将EntityObject用作DTO是不合适的，因为 EntityObject具有EF所给定的实体键，应该视为实体，既然是实体，就不能穿越层的界定线。我更偏向于在Domain和UI之间使用DTO，而不是Domain和Repository之间。因为Repository维护的是实体的生命周期，而不是DTO。
最后，关于您的Domain和Repository解耦的问题，我已经在您的上个评论中留下了一个案例的下载地址，您可以通过下载这个案例来了解如何在 DDD中引入Repository。