Il livello dell'applicazione è compreso tra il livello dominio e il livello presentazione. Il controller fa parte del livello di presentazione, invia comandi o query al livello dell'applicazione, dove i servizi dell'applicazione li eseguono utilizzando i servizi e gli oggetti del modello di dominio. Quindi i controller sono diversi dai servizi applicativi e probabilmente sono legati al modulo di comunicazione effettivo, ad es. HTTP. Non dovresti chiamare direttamente i servizi di dominio dai controllori, questo potrebbe essere un segno di codice fuori posto.
Domain Driven Design: Domain Service, Application Service
- Servizi di dominio: Incapsula logica aziendale che non rientra naturalmente all'interno di un oggetto di dominio, e NON sono operazioni tipiche CRUD - chi apparterrebbe a un repository.
- Servizi applicativi: utilizzati da utenti esterni per comunicare con il sistema (si pensi ai servizi Web). Se i consumatori hanno bisogno di accedere alle operazioni CRUD , saranno esposti qui.
Così il vostro servizio è probabilmente un servizio applicativo e non un servizio di dominio, o alcuni servizi parte app, qualche servizio dominio parte. Dovresti controllare e rifattorizzare il tuo codice. Credo che dopo 4 anni questo non sia importante, ma ho avuto gli stessi pensieri con un'applicazione che sto attualmente sviluppando. Questa app potrebbe essere troppo piccola per utilizzare DDD su di essa, quindi i controller confusi con i servizi delle app sono un segno di overengineering qui.
È una domanda interessante quando iniziare ad aggiungere più livelli. Penso che ogni app dovrebbe iniziare con una specie di domain model and adapters per connettersi a quel modello di dominio. Quindi, se l'app è abbastanza semplice, l'aggiunta di più di 2 livelli potrebbe non essere necessaria. Ma questo è solo un pensiero, non sono così esperto con DDD.
Il controller richiede le richieste dalla vista passando la richiesta, o parte pertinente, al modello. MVC è un'architettura e potrebbe sicuramente essere applicata a winforms e alle app Web. Mi permetto di dissentire per quanto riguarda la posizione del controller. The View è sicuramente l'unico UI-Layer e il punto di MVC è di mantenere questo UI-Layer separato dal controller. Il tuo punto è ben preso però; Grazie per la risposta. – Louis
-1. I controllori sono coordinatori di richieste/comandi.In un'architettura esagonale i controllori sono proprio sopra i servizi di applicazione/i gestori di comandi/gestori di query. Controller è un traduttore di richieste ed è accoppiato con il protocollo di comunicazione (livello superiore) e il comando/gestori di query (servizi applicativi da un livello inferiore). I controller possono essere visualizzati come facciate di servizi applicativi perché traducono e preparano il comando/query/messaggio per essere elaborati dai livelli di livello inferiore (gestori di applicazioni/gestori di query di comando). – Tudor
-1 perché i controller non hanno nulla a che fare con DDD. È irrilevante dove si mettono i controller, si potrebbe dire che i controller sono solo coordinatori di messaggi/comunicazioni e sono accoppiati in entrambi i modi: ui e servizio applicativo. Potresti avere controller in un contesto limitato in cui non esiste un'interfaccia utente (un puro contesto di comando). E potresti avere un contesto limitato solo per la presentazione (un componente aziendale composito costituito solo per interrogare 2 o più contesti limitati). Post scriptum i controllori hanno un basso accoppiamento con l'interfaccia utente, si aspettano solo una serie di parametri di richiesta, non importa da dove. – Tudor