Servizio applicazioni - parte del Contesto Limitato?

3

Ho difficoltà a capire dove i servizi applicativi si integrano con l'architettura DDD e Onion. Fino a qualche giorno fa ho pensato a loro come parte del modello di dominio, ma ho iniziato a chiedermelo.

So a cosa servono i servizi di applicazione.

  • Orchestrare i casi d'uso.
  • Recupero dei root aggregati tramite repository (repo astrazioni).
  • Invio di email, gestione di sessioni di sorta ...

Tuttavia, ho visto spesso che gli autori non implementano affatto i servizi di applicazione, ma piuttosto scaricano queste responsabilità sul controller MVC e questo mi confonde.

La mia linea di pensiero va:

  • I servizi per le applicazioni fanno parte di un contesto limitato? Non ne ha voglia, poiché il Contesto Limitato è composto da Aggregati. Non ho mai visto un servizio applicazioni dichiarato come parte di un aggregato.
  • I servizi per le applicazioni fanno parte del livello più esterno di Onion? No, gli elementi relativi alle interfacce utente / API / infrastruttura vivono lì.
  • Quindi dove si adatta un servizio applicativo? Se dovessimo spostare ciascun Contesto Limitato in uno spazio dei nomi / assembly / libreria autonomo, il Servizio Applicazione non sarebbe in grado di seguire.

Cosa mi manca? Forse un servizio applicativo può lavorare con modelli di dominio rigorosamente da un singolo Contesto Limitato (più il Kernel condiviso)? Ciò potrebbe consentire il raggruppamento del Servizio Applicazione con il rispettivo Contesto Limitato.

    
posta robotron 25.07.2018 - 22:09
fonte

2 risposte

2

I servizi sono parte del contesto limitato? Sì. I contesti separano aree di significati potenzialmente diversi, e coprono completamente l'intera applicazione, non c'è nulla di "esterno".

Ciò che potrebbe essere fonte di confusione è che i Servizi in realtà non fanno parte del Dominio . Potresti pensare che il Domain -Driven Design riguardi il Dominio, ma per qualche ragione Eric Evans ha deciso di includere materiale tecnico, che in realtà non riguarda il Dominio. Basta guardare i nomi dei Servizi, vengono dall'Ubiquitous Language? Certamente no se finiscono con "Servizio".

Ecco una delle mie presentazioni, una parte delle quali mette in discussione l'idea di Servizi e in particolare esamina alcuni dei Servizi di Vaughn Vernon e mostra come modificarli facilmente in "Oggetti di dominio" reali:

link

    
risposta data 26.07.2018 - 09:28
fonte
2

Non so se comprendo correttamente il tuo dubbio, ma se quello che vuoi sapere è se includere o meno un servizio applicativo per ogni contesto vincolato, la risposta è sì. Puoi creare e includere sia un servizio applicativo che tutta la struttura dell'architettura DDD se ha un senso per la tua soluzione.

Ogni Contesto Limitato, può avere un'architettura N-Layered. Puoi visitare il progetto di esempio di DDD di Vaughn Vernon su github, dovrebbe essere sufficiente a risolverlo.

IDDD_Sample

Nell'IDDD_Sample di Vaughn Vernon, ha 3 contesti limitati come il contesto agilepm e il contesto di collaborazione che include l'applicazione, l'infrastruttura, il modello di dominio al suo interno. Inoltre, ha un kernel condiviso di nome Common.

    
risposta data 26.07.2018 - 05:00
fonte