Quale livello genera comandi per servizi dipendenti?

Question

Quale livello genera comandi per servizi dipendenti?

#1 da (1 voti)
#2 da (0 voti)

1

La nostra azienda lavora con camionisti che effettuano ritiri / consegne di container. La posizione dei contenitori deve essere monitorata.

I driver utilizzano i dispositivi mobili per generare un "DriverReport" (un registro dei loro luoghi di viaggio, orari, ritiro / ritiro container, ecc.). Attualmente funziona con un design prevalentemente CRUD.

Volevamo mantenere un buon SoC così abbiamo creato due servizi:

DriverService
InventoryService

Abbiamo avuto che DriverService ha una dipendenza da InventoryService. Quando è stato inserito un nuovo DriverReport, genererebbe DTO (basato sui dati dei report) che potrebbero essere inviati a InventoryService.

Non stiamo ancora utilizzando CQRS, ma stiamo valutando di passare ad esso.

Sto facendo fatica a capire la relazione tra i servizi, i comandi e BLL. Mi sembra di avere molte domande.

Chi sarebbe responsabile della chiamata al servizio di inventario?

Sarebbe un buon design per un NewTripCommandHandler per generare e inviare un comando UpdateContainerInventory?

Oppure, l'aggiornamento dell'inventario per un nuovo viaggio può essere considerato una logica aziendale? In caso affermativo, un'entità di dominio per Trip genera e invia un comando UpdateContainer?

Oppure, se il client mobile genera sia i comandi specifici di viaggio che quelli di inventario da inviare al servizio appropriato?

Avrebbe più senso prendere le parti specifiche dell'inventario DriverReport e unirle nel DriverService (quindi la dipendenza è interrotta)? E 'ancora un buon SoC? Se lo facessimo, a quale livello potremmo iniziare a pensare all'inventario? L'aggiornamento dell'inventario diventerebbe semplicemente un problema di repository DB, o dovrebbero esserci ancora comandi specifici per l'inventario e / o logica aziendale?

Mi sto perdendo nei dettagli e sembra che più leggo sugli argomenti, più mi confondo.

domain-driven-design architecture separation-of-concerns cqrs

posta mbursill 23.02.2015 - 20:39

fonte

2 risposte

1

Il mio consiglio è di smettere di pensare a servizi, comandi e termini fantasiosi nella progettazione OO.

Consiglio vivamente di modellare la tua logica aziendale senza pensare all'architettura orientata ai servizi, al modo in cui i dati saranno trasferiti dai clienti al servizio, ecc.

Hai un'applicazione. La tua applicazione ha chiaramente due moduli:

Modulo per l'elaborazione di un rapporto del conducente. Non mi interessa davvero come viene generato questo rapporto e da dove provengono i dati in questa fase.
Modulo per l'aggiornamento dell'inventario. Ora non creerei una dipendenza tra il rapporto del conducente e l'elaborazione dell'inventario. Invece creerei un componente che estrae i dati rilevanti dal rapporto del driver e poi lo passi nel modulo di elaborazione dell'inventario.

Una volta che tutto questo è a posto, inizierei a pensare ai servizi (confini). Vorrei fare domande del tipo: "Ha davvero senso creare un servizio di inventario? Avrò un'applicazione client che la chiamerà direttamente?"

Infine, vorrei mettere in discussione qualsiasi logica di business nell'applicazione client. Normalmente modellino e collaudo tutti i miei requisiti di business nel livello dominio. Una volta fatto, comincio a lavorare sull'applicazione client. In questo modo la mia applicazione client è stupida, tutto ciò che fa è aggregare alcuni dati, passarli al livello del dominio, lasciare che il livello del dominio elabori cosa fare con i dati, e infine visualizzare i risultati all'utente.

Aggiornamento 1 Quindi anziché:

var driverReport = new DriverReport();
var inventoryCoordinator = new InventoryCoordinator();
inventoryCoordinator.Process(driverReport);

Avrei:

var driverReport = new DriverReport();
var inventoryUpdate = InventoryUpdateFactory.Create(driverReport);

var inventoryCoordinator = new InventoryCoordinator();
inventoryCoordinator.Process(inventoryUpdate);

Nel primo esempio il coordinatore dell'inventario ha una dipendenza diretta dal rapporto dei conducenti.

Nel secondo esempio, estraiamo le informazioni rilevanti dal rapporto dei conducenti e poi lo passiamo al coordinatore dell'inventario per un'ulteriore elaborazione.

risposta data 23.02.2015 - 21:45

fonte

Leggi altre domande sui tag domain-driven-design architecture separation-of-concerns cqrs

Componenti connesse del grafo non orientato Esecuzione di script in parallelo in base all'albero delle dipendenze

score 0 · Accepted Answer

Potresti considerare SOA se vuoi. Il fatto è che hai a che fare solo con i Comandi. Se si aggiunge il modello di pubblicazione / sottoscrizione (code di messaggi, bus di servizio), è possibile fare in modo che i serivisti pubblichino eventi / messaggi e non debbano sapere chi erano gli abbonati; gli abbonati otterrebbero tutte le notizie e opereranno fuori dai contenuti dei messaggi.