领域模型中Repository接口和Transaction

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

很久没有上JE了，昨天晚上看到了上面这个帖子，难得好贴，但是文中提得的有些观点，我有一些不同的看法。还有一些这个帖子中没有涉及到的。
  lifethinker 提到应该把Repository的接口放在Model层，这个我同意（接口应该属于使用者），但原因绝对不是因为Repository接口放在infrastructure，会引起两层之间的双向依赖。即使你将Repository接口放在Model，但是你的实现还是在Infrastructure啊，依赖依旧是双向。难道连实现都要搬移到Model（当然这是开玩笑）？前几天和我的一个同事聊起这个，他提到了应该有区分Entity和领域模型，这个Entity可能就是一个VO，这样的话Repository操作的是Entity，麻烦的是要有从Entity到Model转换的过程。我也有一个自己的观点，既然Model是稳定的，是核心，Infrastructure依赖Model又有什么问题呢?个人观点，欢迎拍砖

  另一个问题是这个帖子没有涉及到的，而也是我的一个疑惑，当涉及到多个Model交互操作时，Service调用事物，可谁来执行Transaction，还是又Repository处理吗？可我看到的Repository是与Model一一对应的，一个个独立的Repository如何能处理交互的事物呢？是否也要对Service做对应的Repository？

Transaction应当放在services里，我觉得

Service,请问如何操作，能给出代码吗？

直接看看这个sample吧。 事务的处理不应该放到repository中的，应该是service的职责。
http://dddsample.sourceforge.net/

不好意思， 我并没有从这些代码看到事物的处理，在DDD中Service本身作为一种接口，它是独立于模型的。也就是对软件中的行为进行建模，而我们的持久化都是与模型一一对应的，我了解事物的调用应该在事物中，可是执行该由谁来呢？

public final class BookingServiceImpl implements BookingService {

    private final CargoRepository    cargoRepository;
    private final LocationRepository locationRepository;
    private final RoutingService     routingService;
    
    //部分代码略
    @Override
    @Transactional//事务annotation
    public TrackingId bookNewCargo(final UnLocode originUnLocode,
                                   final UnLocode destinationUnLocode, final Date arrivalDeadline) {
        // TODO modeling this as a cargo factory might be suitable
        final TrackingId trackingId = cargoRepository.nextTrackingId();
        final Location origin = locationRepository.find(originUnLocode);
        final Location destination = locationRepository.find(destinationUnLocode);
        final RouteSpecification routeSpecification = new RouteSpecification(origin, destination,
            arrivalDeadline);

        final Cargo cargo = new Cargo(trackingId, routeSpecification);

        cargoRepository.store(cargo);
        logger.info("Booked new cargo with tracking id " + cargo.trackingId().idString());

        return cargo.trackingId();
    }

我个人的理解是，这里有一个比较模糊的地方是 application层的service和 领域层的domain service的区分问题。具体还在学习中。但是从以上的代码来看的话，事务被放到了BookingServiceImpl 这个application层的service中的。

你这里使用了annotation，若是你使用一种本身不支持annotation的语言你如何处理，在DDD中对于每一个Aggregate的Root才会有Repository，Reopository保证了一个Aggregate内持久化完整性和一致性，可是谁来保证两个Aggregate之间交互的持久化的完整性和一致性呢?

对于Application Layer的Service我觉得更多的完成流程的服务,而Domain Layer的Service才是真正业务上的Service。

如果不支持annotation，当然直接把事务的处理放到这个bookNewCargo方法中。例如使用transactionTemplate之类的。




我也才开始学习，没办法很好的解释这个问题。我个人觉得事务的保证应该是又需要的时候就需要应用。领域内的问题领域内解决吧。



这一点我很占同。

Repository 归于model我比较认同，但是 我认为dao是更细粒度的，我认为应该为
基础设施层，repository 构建在dao 之上

Infrastructure 怎么依赖Model法？以前俺老师老告诫我别弄出循环依赖，我还真想见识一下。

事物是业务要求的，在业务上面搞一层出来做事务就行了，以前时髦的facade层就可以用来搞这个，跟repository隔老远呢，