I modelli di dominio dovrebbero istanziare altri modelli di dominio?

2

Sto leggendo Domain-Driven Design al momento e sto cercando di capire cosa dovrebbe andare nei servizi e cosa dovrebbe andare nei modelli di dominio.

Dire che c'è un'applicazione in cui puoi prenotare posti per concerti.    Quindi dopo questo hai un certo tempo per pagare il    biglietti, dopodiché la prenotazione non è valida.

Il metodo seguente per prenotare i posti è in un servizio. Se un utente non ha ancora effettuato una prenotazione per un concerto o la prenotazione non è valida, ne viene creato uno nuovo, altrimenti la prenotazione dell'utente viene aggiornata. La logica principale del metodo è in una dichiarazione if se non altro. Questo potrebbe essere spostato nel modello di dominio Concert passando la vecchia prenotazione e restituendo la nuova prenotazione, quindi il modello di dominio Concert creerebbe le proprie prenotazioni. È un approccio migliore per spostare la creazione di SeatReservation nel modello di dominio?

   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);
            ticketDao.saveSeatReservation(seatReservation);
        }
    } else if(seatReservation.isValid() 
              && numSeatsReserved - ticketReserve.getNumSeatsReserved() 
                 <= numTicketsRemaining){
        seatReservation.setNumSeatsReserved(numSeatsReserved);
        ticketDao.editReservation(seatReservation);
    }

    return seatReservation;


}
    
posta Benten 17.06.2016 - 16:41
fonte

1 risposta

2

Should domain models instantiate other domain models?

I modelli di dominio non sono istanziati, invece istanziamo entità, aggregati, radici aggregate, ecc.

The method below to reserve seats is in a service.

L'uso del termine disadorno "servizio" è soggetto a errori. Dai un'occhiata a questo , che discute le differenze tra servizi di dominio e servizi applicativi, per esempio.

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

Ci sono molti modi per farlo, per esempio, penso che quello che stai descrivendo più o meno si adatta alla nozione di un servizio di dominio.

La tua domanda inoltre non chiarisce quanti contesti limitati abbiamo a che fare qui, in particolare, se le prenotazioni sono in un bc e i biglietti sono in un altro, anche se sembra suggerire che potrebbero essere separati.

Altre complessità potrebbero rendere l'affare con i biglietti proprio come trattare con le prenotazioni che sono appena state pagate (e quindi non scadono). Per uno, il numero totale di posti assegnati nelle prenotazioni e i biglietti per ogni concerto dato ti dice se c'è disponibilità, e la distribuzione che attraverso due domini richiederà uno sforzo non banale. Per un altro esempio, se l'utente desidera effettuare una modifica post acquisto (come aumentare il numero di posti a sedere o annullare). Potrei obiettare che appartengono allo stesso bc per iniziare, e in seguito potrai separarli quando sei pronto ad affrontare le complessità più complesse. E ancora un altro esempio, aggiungendo sofisticazione come l'assegnazione dei posti, quindi le prenotazioni e i biglietti potrebbero finire con ancora più duplicazioni. Quindi, ancora una volta, potrei obiettare che la prenotazione contro il biglietto è solo un cambiamento di stato sullo stesso aggregato nello stesso bc, a meno che non si voglia gestire la complessità dei sistemi distribuiti fin dal momento in cui si sta ancora truccando le funzionalità di base .

    
risposta data 17.06.2016 - 17:48
fonte

Leggi altre domande sui tag