I'm reading Domain-Driven Design at the moment and I'm trying to understand what should go in services and what should go in domain models.

Say there is an application where you can reserve seats for concerts. Then after this you have a certain amount of time to pay for the tickets, after which the reservation is invalid.

The method below to reserve seats is in a service. If a user has not yet made a reservation for a concert or the reservation is invalid a new one is created, otherwise the user's reservation is updated. The main logic of the method is in one if/else statement. This could be moved into the Concert domain model by passing in the old reservation and returning the new reservation, so then the Concert domain model would create its own reservations. Is it a better approach to move the creation of the SeatReservation into the domain model?

   private SeatReservation reserveSeats(int concertId,
                                          int numSeatsReserved,
                                          int userId) throws DataAccessException{

    SeatReservation seatReservation = ticketDao.getReservation(userId, convertId);
    long numSeatsRemaining = ticketDao.getNumRemainingSeats(concertId);

    if(seatReservation == null || !seatReservation.isValid()){
        if(numSeatsReserved <= numSeatsRemaining) {
            seatReservation = new SeatReservation(userId, concertId, numSeatsReserved);
    } else if(seatReservation.isValid() 
              && numSeatsReserved - ticketReserve.getNumSeatsReserved() 
                 <= numTicketsRemaining){

    return seatReservation;

  • FYI, I don't follow where ticketReserve comes from or why that is what is returned.
    – Erik Eidt
    Commented Jun 17, 2016 at 15:32

1 Answer 1


Should domain models instantiate other domain models?

Domain models are not instantiated, instead we instantiate entities, aggregates, aggregate roots, etc..

The method below to reserve seats is in a service.

Using the unadorned term "service" is error prone. Have a look at this, which discusses the differences between domain services and application services, for example.

Is it a better approach to move the creation of the SeatReservation into the domain model?

There are many ways to do this, for one, I think what you're describing more-or-less fits the notion of a domain service.

Your question also doesn't make it clear how many bounded contexts we're dealing with here, specifically, whether reservations are in one bc and tickets are in another, though seems to hint that they might be separate.

Other complexities could make dealing with tickets just like dealing with reservations that just happen to be paid for (and thus won't timeout). For one, the total number of seats allocated in reservations and tickets for any given concert tells you whether there is availability, and distributing that across two domains will require non-trivial effort. For another example, if the user wants to make a change post purchase (like increase seating, or canceling). I might argue that they belong in the same bc to start, and you can later separate them when you are prepared to deal with more complexities that will involve. And yet another example, as you add sophistication like seat assignments, then reservations and tickets might end up with even more duplication. So, again, I might argue that reservation vs. ticket is just a change of state on the same aggregate in the same bc, unless you want to deal with distributed systems complexity right out of the box while you are still hashing out the basic functionality.

  • Thanks for the answer and the link. If I move the creation of SeatReservation's into the Concert entity is this then similar to the Invoice method of PurchaseOrder in the link you sent? I want to move it into Concert because there could be more restrictions on reserving seats like upper-bounds specific to each concert etc.
    – Benten
    Commented Jun 17, 2016 at 16:33
  • Yes, I believe so.
    – Erik Eidt
    Commented Jun 17, 2016 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.