Come si suddivide il livello dell'interfaccia utente (MVC) in modo che più team possano lavorare su di esso?

Question

Come si suddivide il livello dell'interfaccia utente (MVC) in modo che più team possano lavorare su di esso?

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

2

Sto cercando di suddividere un'applicazione di grandi dimensioni in modo che più team possano lavorarci sopra. Ho creato un numero di contesti limitati per il livello del dominio. Ogni contesto limitato è contenuto nella propria soluzione con un livello di infrastruttura e un livello di servizio. C'è un repository per radice aggregata.

Come gestisci il livello dell'interfaccia utente? Si prega di consultare questo articolo qui: link . Diciamo che ho tre contesti limitati. È normale suddividere l'interfaccia utente in tre aree MVC. Ogni area rappresenterebbe un contesto limitato. Pertanto il team che sviluppa il contesto limitato 1 svilupperebbe anche l'Area 1. È normale farlo:

1) La squadra 1 sviluppa Area 1, che fa riferimento all'app MVC5 principale

2) La squadra 2 sviluppa Area 2, che fa riferimento all'app MVC5 principale

3) Il Team 3 sviluppa Area 3, che fa riferimento all'app MVC5 principale

È normale mappare aree a contesti limitati come questo? Se la risposta è no, come si suddivide il livello dell'interfaccia utente (MVC) in modo che più team possano lavorarci?

domain-driven-design mvc

posta w0051977 18.09.2017 - 12:38

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design mvc

È opportuno fare affidamento sul fatto che lo stato non esiste per gli altri utenti che arrivano allo stesso indirizzo? Dove implementare la convalida dei dati URL in Node / Express?

score 2 · Answer 1

Is it normal to map Areas to Bounded Contexts like this?

Di solito il buon senso ci dice che le decisioni architettoniche come la divisione di un sistema in "contesti limitati" dovrebbero essere guidati dai requisiti di un sistema. Tuttavia, è del tutto normale che i progetti software seguano molto più la struttura di comunicazione dell'organizzazione che crea quel progetto. Il nome per questo è Legge di Conway , e ha circa 50 anni.

Questo non è necessariamente un aspetto negativo purché funzioni per te e la tua organizzazione nel contesto del tuo progetto attuale. Tuttavia, tieni presente che alcune attività possono essere risolte meglio adottando la struttura del team per l'attività anziché eseguirla al contrario.

score 0 · Answer 2

Anche mantenere le funzioni nello stesso contesto limitato nell'interfaccia utente ha senso per me. Potresti utilizzare la modularizzazione dei moderni framework per dividere l'interfaccia utente in team: ad es. Angular4 si basa principalmente su componenti alternati. Ad esempio, potresti avere:

una pagina di gestione degli utenti
una pagina di gestione del tempo

nella stessa applicazione, sia come componenti unici su cui si lavora allo stesso tempo. Probabilmente non puoi separarlo completamente, tuttavia: se vuoi avere tutto in una sola applicazione, cose come l'Autenticazione / Autorizzazione dovrebbero essere implementate in componenti (per lo più nascoste) applicate a tutte le pagine dell'applicazione; significa che devi avere un team dedicato a lavorare su queste funzionalità che si sovrappongono al contesto o far lavorare ogni squadra su di loro, il che potrebbe diventare difficile da coordinare. Hai anche la possibilità di separare completamente le UI e metterle in diversi frontend, ma sarebbe molto più complicato per l'utente finale.