本人的BAC框架发布0.2版，兼谈DomainEvent模式

这种方式唯一的好处就是可以把CRUD中的CUD等数据库的操作异步执行~~

首先以LZ的例子说一下，班机有多少学生上课，本身，一个班机和学生，本身应该是两个domain model，因为很简单，学生和班级在学校整个这个context下都是拥有全局identity的。

而，一个班机拥有多少学生，本身可以把学生的统计情况作成Value Object，里面包含Student number还有其他统计情况即可。

再说回来你本身问题，一个Domain Aggregate Root本身就是第一次创建于Factory或者从Repository取得，也就是说Dao要在这两个里面进行注入，而一个Domain Aggregate Root对象应该是在通过Repository的Save之后才拥有Dao的访问权利。

而对于Repository的Dao注入，当然是在类的创建时候了--constructor。那个文章，我也看了，属于没有实际应用经验的杞人忧天罢了，记住了，不要太崇洋媚外了，不一定用英文写的文章就一定会使多高深的，就一定要去盲目追从！

感觉有点类似适配器，在实体与服务之间加入了一个接口，达到解藕的目的。
楼主有没有DomainEvent更详细的说明。

首先，LZ的想法是很不错的。在目前的WEB开发中（注意，我强调的是WEB），Model基本上都是贫血的，里面只有数据以及自身内部数据的处理。其他操作都交给Service来处理。

LZ提到的问题，我的理解是，本来应该属于Model自身的数据处理，但是要考虑到性能，所以需要懒加载。但是，懒加载也有解决不了的问题，比如返回班级里面学生的个数。如果使用Hibernate的懒加载，那么是需要把所有的学生读取出来然后取一个size，这里就存在一个性能问题了。当然，不知道我有没有理解LZ的意思啊。

其次，LZ的做法让人感觉耦合了。其实，耦合看你怎么看了，LZ的是API耦合。假设，我们使用Interceptor去实现，难道就没有耦合了吗？那只不过不是API耦合而已，是数据耦合，因为你同样要识别getStudentSize这个方法。

另外，Model里面耦合Service这个肯定不是上上策（当然，不能说是错误）。

LZ继续加油吧。

多谢。我这个DomainEvent本身还是处于一个试验性质，肯定有很多设计不合理的地方。大家对我文章批评了这么多(我觉得主要是举的例子不合适)，我会仔细思考如何改进DomainEvent框架，看能否进一步解耦。大家还请多多对我的框架本身多多试用多多批评。BAC框架0.2除了DomainEvent之外，还有验证码等组件，希望大家对此多提意见。

域对象分为贫血模型和富血模型，您的设计应该属于后者。对于贫血模型，对于getStudentSize()这类lazy load的东西，我在guzz中设计的模型是“自定义属性”。

class T{

public int getStudentSize() ;

}

然后在领域对象映射文件中配置字段加载属性自定义加载方式loader="xxxxx.xxxx"。基本上，域对象设计不变（还是简单的POJO）。由loader负责这类特殊内容的自定义读取，感觉比DomainEvent的方式清晰一些。您看是否有参考价值。

个人觉得，你这个框架好不好应该从方面去说：比如可维护性、解耦等等。这样大家能和自己使用现状有所比较，自认能体会到其好坏。

楼主可以看一下最新Jdon framework,里面已经有Domain Event的实现，而且是异步的。

我知道。其实最早看到这个模式就是在那里。我文章里虽然只写了同步的，但是其实我框架本身同时支持同步和异步。

我觉得LZ这样做挺好的。一直认为领域模型应该脱离具体的技术实现。每次都依赖DAO总觉得有点别扭