领域模型中Repository接口和Transaction

那我想问问你的Repository实现里面会不会使用Model呢？简单来说比如你的UserRepository 有一个Save的方法，你的参数是什么？是UserEntity吗？

贴代码来看看

我承认说的极端了点，毕竟大伙儿以前都是这么依赖过来的。但是我觉得对repository来讲，他所看到的都不过是一些可以可持久的东西(随便给他一个名字IPersistable)，就像一个锤子满眼都是钉子，即使我们的域模型世界丰富的很，但是在锤子看来，一切能揍的就是钉子。很多时候我们直接就把这个IPersistable当作域模型的俄一部分了，而hibernate的hbm文件正式把这部分信息给剥离出来了弄成了hbm文件，这样子咱们的pojo里就和这个infrastructure没啥关系了。

我用的是统一的Repository，不存在单独的UserRepository，所有可持久化的对象都是以IEntity 的身份传进去的，hibenrate找到对应的hbm后持久。



repository管存储加载，不可能主管事务，他只不过是配合执行而已。
主管事务的是UserService或者之上的一层，我建议在上面还有一层统领全局Facade，然后在这个facade的实现中，可以弄一个service队列，各种Service，如Authentication&Authorization,logging,transaction，customizedService，整整齐齐排好队，这样比直接在UserService上直接搞AOP要更好些。

我有不同看法：针对客户来说Model是核心(这个领域逻辑还真不一定稳定呢),但是对我们搞软件的来说，一个平台一个架构一套infrasturcture要比model核心的多，把infrastructure搞好了，大伙儿能用他连做N个应用呢，日积月累慢慢改进也很稳定。
所以俺们写代码的才不愿用心去搞什么领域，有这个时间搞架构对我们来说划得来得多。

这种做法是错误的，基础架构的重用不可能是完全的，结构可以重用难道每个Repository的实现也可以吗？
不知道你的IPersistable是什么样的接口，让所有的Domain都实现吗？
统一的Repository是什么样的，难道你的所有Domain都在一个聚合边界内？

强调一下，我说的是数据库的事物，难道也可以在应用层完成？

最好还是贴代码吧，很期待你的代码

1.你可以认为我这个“统一的Repository”就是一个范型的DAO，为什么要弄出所谓的"每个Repository"?
我代码写得烂，写一段伪代码吧:
public interface IRepository{
       public IEntity read(IEntity entity);
       public IEntity create(IEntity entity);
       public IEntity update(IEntity entity);
       public void delete(IEntity entity);
       public List<IEntity> query(QuerySolution qs);
}
2.我提到的IPersistable实际上不一定是一个接口，他只是以某种形式为pojo提供Repository持久化它时需要一些信息，就像hbm里的内容。
3.上面两点做到了，基础架构现在可以重用吗？
4.我觉得你没理解好Repository或者是聚合的概念，一个pojo(好吧，非要严谨的话就这样说：每一个Aggregate的Root才会有Repository)必须有一个repository与之对应，但是一个repository可以对应n个pojo的。
5.我都怀疑你说的是事物还是事物了，事务并不是数据库独有的概念，再说数据库之间还有分布式事务呢，JTA总听说过吧。用过spring的申明式事务没？如果我们都没会错意的话，谨慎怀疑你没实战过。

http://www.iteye.com/topic/283668


首先，Repository和DAO是两个概念，其次，Repository的接口在Domain Layer，实现在Infrastructure Layer

Infrastructure == 基础结构

我是理解的不深，
POJO是贫血的，在DDD中会有POJO吗？
POJO对应Repository？ 一个Repository对应多个Pojo？

如果你没有JTA和Spring呢？我希望的实现不是局限于Java

第一条，你说的这个有什么意思？dao是我这个代码的实现，repository是ddd的领域模型的概念，是两个不同的概念，这个自然不用你讲，“接口在Domain Layer，实现在xxx"，真要扣字眼，说“接口定义在某层，使用在某层，实现在某层”更好些。
第二条，还是抠字眼，等于基础结构了有怎样，还有很多人说是基础设施呢。现在你能回答我的2,3点了么
第三条,我倒是希望实现是局限于java的，因为相比其他的平台我更熟悉Java，同时希望你的实现不是局限于数据库的，这让我想起以前做一些项目的时候，甲方更希望我们把本来打算写在java里的逻辑搬到他们的数据库里的存储过程里去，有一次我写了5个2千行的oracle下的package，吐血。

我想知道的是，你怎么写出一个Repository的实现而脱离Domain Object？

你的IPersistable是什么结构，能贴上代码？
基础结构和基础架构本身就是两个完全不同的概念，你能说这两个是一个意思？


???



你要这样说我就无语了

第一个IRepository你用hibernate来实现它看看，然后构建infrastructure的时候需要domain object的那些类么？这不就消除依赖了么。



这边人气太低了，讨论不起来，放眼看过去都是我的回文。

事务事务,总是在说Spring,hibernate,领域驱动模型设计又与春天里冬眠有什么关系.
不要用了Hibernate就认为Entity.只是一个POJO,我觉得除非这些框架是按照领域驱动模型设计的,否则都不能以领域驱动模型来适应它.Hibernate的面向对象思想虽然很好,不过在这里最多也属于基础层的东西,甚至不用它更好.存储说明它可以是DB也可以不是.我觉得如果在这里控制事务,就像SSH中的Hibernate中控制事务差不多.如果不控制,那缓存,DB里的东西在出错时回滚问题,,,,,,,