这样对吗？
要是对的话，虽然employee在缓存中，不用每次都查数据库取得，但是每次update，我用的是hibernate，数据库会执行很多无用的语句，insert 然后在update 不如直接用dao就执行一条insert快。请banq老师仔细说说。
关键这个问题弄清楚，聚合和实体的区别是边界大小不同，聚合是一个根实体为中心，带着很多小卫星。
如果你设计成，员工是考勤记录的聚合根，那么下面实现方法被局限这个设计边界中，你如果又使用Hibernate之后，边界就越小，就象前面有很多定语，那么你就会被限制，如果你这时欲望又很多，就痛苦疑惑了。
解决办法：权衡你的欲望合理与否，如果遵从自己的欲望(不想数据库执行太多无用语句)，那么就重新考虑前面的定语，首先Hibernate是否可优化，或不用？再次是否聚合根设计有问题？
我认为，聚合根设计有问题，将考勤记录划为员工聚合边界内，说明他们之间关系紧密，那么如果员工的销售记录是否也划在其中呢？
领域建模有三个大小不同边界，领域边界，聚合边界，类边界。哪些应该放在哪个边界中，是有反复考量的。
当你放入一个对象进入边界时，有一个反方向力在对抗它：就是低关联，高聚合。所谓高聚合，不是一般的聚合，而是一种最紧密的组成关系，没有你我就活不了，否则不用划。
因为业务功能发生关系的就尽量不用划入聚合边界，因为业务活动一旦发生，他们就自然产生关系，比如员工一旦在考勤这个活动场景中，就自然和考勤发生关系，并自然拉下考勤记录这泡屎。
而我们传统数据库思路，就只看到考勤记录这个静态存活时间很长的这泡屎，然后把员工和屎划上关系，并且强调“就是你拉的屎”，他根本不关系是否看到“考勤”这个蹲下拉屎的动作，依据倒推原则“有记录就有考勤”，那么考勤动作谁来设计呢？上帝做吗？
有可能以上回答你不是很理解，如果你想在现有设计+Hibernate这些定语限制下，又想操数据库那份心，我也没办法帮你，因为对于我来说，是瞎操心。
而我们传统数据库思路，就只看到考勤记录这个静态存活时间很长的这 ...
这句话怎么理解？注意我上面一句话：
因为业务功能发生关系的就尽量不用划入聚合边界，因为业务活动一旦发生，他们就自然产生关系，比如员工一旦在考勤这个活动场景中，就自然和考勤发生关系，并自然拉下考勤记录这泡屎。
两者独立开后，通过"考勤"这个功能实现会将两者联系一起，比如你做了一个页面，上面有”考勤“这个菜单，员工选择它，就完成了考勤，同时产生考勤记录，然后你用数据库或文件保存一下这个员工的考勤记录。
用数据库作为实现保存，不是用数据库来主导设计。两者有区别，好好体会一下。
[该贴被banq于2011-04-10 13:06修改过]
考勤记录/销售记录属于员工，但是员工不一定时时刻刻都非要有销售记录和考勤记录才行。
[该贴被pye于2011-04-11 09:39修改过]
前面大家已经说了，聚合是一种强关联。我想说的是，这个强关联概念估计DDD是直接从uml引进的，是因为有谁的存在而存在。
有这种强关联的概念，我们在看看楼主的问题——“repository是针对聚合跟建立还是针对实体对象啊？”我认为资源库就是针对聚合根建立的。
聚合根是老大，它将它周围那些“小卫星”视为己物，不容别人侵犯。举个例子。美女是个聚合根，她住在A处。你和美女交谈，死缠烂磨知道她住在A处。然后你私底下将美女住在A处高速你的死党，结果一传十就传开了。问题是传的过程中，某人传错了，把美女住在A处说成B处。居委会居然同意这种流言，将美女住在B处登记在案。事实上，我们的程序很可能就是那个部分青红照白的“居委会”。
要解决这个问题两点，一是美女根本就不随意外传她的住地。居委会要知道美女地址只能问美女。二是，美女告诉你住地发表声明，大概意思是，她与你的谈话最终解释权归美女，谈话完毕，你把A地说成任何地点都与她没有关系（也就是给了个地点对象拷贝）。
另外，员工和考勤是不是聚合关系也没有定论，关键看问题域的关系。比如，财务部门每月造工资表。如果该员工没有考勤表，财务部门就当非员工处理，不给做工资表。这样，员工和考勤表无疑成了聚合的强关联了。
两者独立开后，通过"考勤" ...
请banq老师看看我这样理解对不对。
class employ{
}
class RecordWork{
Date comedate;
Date godate;
employ em;
}
// 记录考勤场景类
class recordEmploy{
private recordWorkReposity rwr;
void recordEmployWork(){
r = recordWorkFactory.create();
rwr.save(r);
}
}
在员工类里没有考勤的关联，只是单向关联，查看的时候从recordWorkReposity 查询。
记录考勤场景类 在服务中实现，而不是仓储，仓储只是一种结果记录。
// 记录考勤场景类
class recordEmploy{
private recordWorkReposity rwr;
void recordEmployWork(){
r = recordWorkFactory.create();
rwr.save(r);
}
}
recordWork employ 是俩个独立的聚合体；所以俩个都有仓储；
记录考勤场景类 也可以理解成服务。
由于recordWork employ 是单向多对1 的关系。
增加recordWork记录 我就在服务里直接直接引用仓储完成。不可以吗？
还有我有点不明白 场景这个东西的含义了。比方说人 在家的行为 跟在公司的行为 都是人的行为。我要是设计人这个实体的时候是 class person implements Home ,Factory {}
还是设计俩个人在家，人在公司俩个场景？ class person {} 在家跟在公司的行为不在person身上实现。而是 把person 当参数传入场景类里？
class AtHome implements Home{
bringUp(person);
}