一个很困惑难以理解的想象，人类的认识总是想寻求一个一劳永逸的解决办法，比如是“ET”或“神仙姐姐”干的，逻辑思维很合理和完美，
但问题“ET”与“神仙姐姐”符合现实吗？
把仓储或服务注入实体，这是DDD明确反对的，领域上也是不可理解的。
这么干的原因往往是偷懒或着对领域理解不够深刻造成的。
持久化:
持久化自身：不应放在(myMethodCommon中)
EntityRepository repository = new EntityRepository();
repository.save(entity);
(如果在方法中实现自身持久化，你是使用ActiveRecord模式)
持久化其他(Entity2)：意味着Entity与Entity2存在某种业务联系，Entity2的生命周期是否为Entity所决定
public class Entity{
public Entity2Collection Entity2s = new Entity2Collection();
public void myMethodCommon(){
//持久化
Entity2 entity2 = new Entity2();
....
Entity2s.add(Entity2); <-- Entity2Collection.add 如何保存持久化，这是发挥架构的威力的地方
}
}
服务调用：当我们想在一个方法中调用服务来，
意味领域上往往Service内对象(Entity3)并不想Entity知道它是谁、是怎么工作？（也许Entity也并不想知道）
如果觉得实体里需要调用Service的地方，其方法myMethodCommon本身就是领域服务EntityService的一个方法。
public class EntityPubService <--因为banq没给具体场景，这个“pub”是举例用的，实际应该领域里的一个动作
{
EntityBusService bus; <- 这个可能是一个设施服务层的服务，是架构发挥作用的地方。。。。
public void process(Entity entity) <-参数不一定直接使用Entity，可以是其他与Entity相关的
{
bus.send(entity);
}
}
public class EntitySubService <--因为banq没给具体场景，这个“sub”是举例用的，实际应该领域里的一个动作
{
public void process(Entity entity)
{
Entity3Repository repository = new Entity3Repository();
Entity3 entity3 = repository.find(1); ///(随便写的1)
entity3.status = 1;
entity.reference = entity3.id
.......
}
}
myMethod、myMethod2、myMethod3的公共部分如果用到了EntityService的方法，
说明myMethod、myMethod2、myMethod3很可能是一个领域服务的方法，
Entity4Service.myMethod
Entity5Service.myMethod2
Entity6Service.myMethod3
否则可以是一个实体的方法如
Entity4.myMethod
Entity5.myMethod2
Entity6.myMethod3
是否属于领域方法还是实体方法，可能是动态，是业务本身决定的，
如果哪天Entity4.myMethod需要的添加一个服务来配合，就需要重构
实体：
public class Entity4
{
public void myMethod(Entity entity){
entity.myMethodCommon();
}
}
public class Entity5
{
public void myMethod2(Entity entity){
entity.myMethodCommon();
}
}
public class Entity6
{
public void myMethod3(Entity entity){
entity.myMethodCommon();
}
}
public class Entity4Serivce
{
EntityPubService entityPubService; <- 发挥架构威力(Ioc注入)
public void myMethod(Entity entity){
entityPubService.process(entity);
entity.myMethodCommon();
}
}
public class Entity5Service
{
EntityPubService entityPubService; <- 发挥架构威力(Ioc注入)
public void myMethod2(Entity entity){
entityPubService.process(entity);
entity.myMethodCommon();
}
}
public class Entity6Service
{
EntityPubService entityPubService; <- 发挥架构威力(Ioc注入)
public void myMethod3(Entity entity){
entityPubService.process(entity);
entity.myMethodCommon();
}
}
如果Entity是一个Domain Event，EntityBusService可能就会选择CQRS来实现，
你选择SOA或EJB服务总线也可以，只是“火车”或“飞机”的区别而已。(哪天我可以介绍具体场景的可能有助进一步理解)
（服务的注入我都舍不得用标签，而是根据类名称，比如一Service结尾就认为是领域服务，即符合DDD规范，又干干净净）
（架构最好能做到“随风潜入夜，润物细无声”）
[该贴被clonalman于2012-08-31 10:22修改过]
