DDD: servizio o deposito

3

Sto sviluppando un'app in modo DDD. E ho un piccolo problema con esso.

Ho una tariffa (tariffa aerea) e oggetti FareRepository. E a un certo punto dovrei caricare ulteriori informazioni sulla tariffa (da un server, call server API) e configurare queste informazioni sulla tariffa esistente.

Suppongo di dover creare un servizio applicativo (FareAdditionalInformationService) che si occuperà di ottenere dati dal server e aggiornare la tariffa esistente o inserire la logica di business nell'oggetto Fare. Tuttavia, alcune persone mi hanno detto che è necessario utilizzare FareRepository per questo problema.

Non so quale posizione è migliore per il mio problema Servizio o deposito.

UPDATE:

Dopo una ricerca, sono giunto alla conclusione che il posto migliore per recuperare informazioni tariffarie aggiuntive è un servizio come (AdditionalFareService).

Il codice sarebbe simile a questo:

//create service for fetching fare information
AdditionalFareService service = new AdditionalFareService();
//get a fare by Id
Fare fare = fareRepository.GetById(myFareId);
//Obtain information from service
var fareInformation=service.getAdditionalInformation(fare)
//Add it to the fare.
fare.AddInformation(fareInformation);
//save it to the repository.
fareRepository.Save(fare);
    
posta tikhop 08.11.2012 - 16:10
fonte

4 risposte

2

Sto presumendo che la InformazioniInfo fornisca dettagli su una determinata Tariffa (ad esempio termini e condizioni speciali, commissioni di modifica, ecc.)

Hai bisogno di un modo per creare e salvare un evento informativo per associarlo alla tariffa. In questo caso, direi fornire metodi sulla tariffa che fa al posto tuo.

L'API sarebbe simile a questa

//get a fare by Id
Fare fare = fareRepository.GetById(myFareId);
//Create a change fee object.
var fareInformation=new ChangeFee(new UsdCurrency(50.00d))
//Add it to the fare.
fare.AddInformation(fareInformation);
//save it to the repository.
fareRepository.Save(fare);

Si noti che sto inviando un oggetto ChangeFee e non un oggetto di FareInformation. FareInformation è una classe base in una gerarchia. Mi sto affidando a O / RM per mappare la gerarchia in una struttura di database per me.

    
risposta data 08.11.2012 - 17:04
fonte
3

Lascia da parte gli schemi per un momento e cerca le responsabilità che devi dividere nel sistema.

  • Accedi al server e recupera informazioni aggiuntive per le tariffe
  • Associa le informazioni recuperate con l'oggetto tariffa esistente
  • Aggiorna oggetti tariffa con informazioni aggiuntive

Di sicuro, la prima responsabilità ha poco in comune con i doveri di FareRepository (mappatura di database / orm degli oggetti Fare). Mettendoli insieme danneggerebbe la coesione del sistema.

Il secondo è chiaramente una responsabilità da inserire negli oggetti Fare.

Il terzo è una responsabilità di FareRepository, poiché deve gestire l'aggiornamento / recupero degli oggetti Fare in qualsiasi stato (con ou senza informazioni aggiuntive associate). Anche se le informazioni aggiuntive meritano una classe specifica.

Quindi, guardando solo alle responsabilità e alla coesione, non ha molto senso usare il repository per accedere al server. Il modello di servizio è una buona scelta per incapsulare la prima responsabilità.

Saluti.

    
risposta data 09.11.2012 - 03:45
fonte
2

Dici che stai facendo questo è un modo DDD, giusto? Quindi il FareRepository dovrebbe preoccuparsi di mantenere i tuoi dati (esponendo i dati della tariffa come se fosse una collezione in memoria).

Se tutto ciò che devi fare è modificare alcune proprietà semplici e salvare, quindi usare solo il repository va bene.

Se c'è una certa logica aziendale che deve essere presa in considerazione quando si aggiornano le classi tariffarie con le informazioni aggiuntive, allora quella logica aziendale dovrebbe essere in un servizio.

Uno dei tuoi commenti ha indicato che ci sono tutti i tipi di considerazioni "esterne" come le pianificazioni dei voli, i costi del carburante, l'aggiornamento e simili da gestire quando si aggiungono le informazioni aggiuntive. Questo richiede quasi che un servizio debba coordinare il processo.

    
risposta data 08.11.2012 - 21:34
fonte
0

Per quanto ne so, sviluppando la tua applicazione in modo DDD stai lavorando sul modello del modello di dominio (http://martinfowler.com/eaaCatalog/domainModel.html).

Se è il tuo caso, tale logica dovrebbe essere incapsulata nel tuo oggetto dominio (tariffa). L'oggetto Fare stesso dovrebbe esporre i metodi che funzionano sull'oggetto dominio e modificarne lo stato di conseguenza.

    
risposta data 08.11.2012 - 17:08
fonte