2014-09-29 11 views
8

Stiamo sviluppando un sistema che è composto da più contesti limitati, ci sono interfacce utente in cui le informazioni visualizzate devono essere rese da più contesti limitati.composizione di più contesti limitati in una singola interfaccia utente,

Un classico esempio di tale interfaccia è la pagina degli ordini di Amazon.com. Dove vediamo sul prodotto (prodotto BC), inventario disponibile (inventario BC), prezzi e così via.

La mia domanda: in tali scenari, in quale contesto limitato sarebbe l'interfaccia utente in diretta? Ricevo come possiamo estrarre dati da più BC per formare la pagina, ma ci sono delle linee guida su dove deve risiedere la pagina stessa?

Domande simili here e here, si occupano di come ottenere informazioni da più BC, ma non indirizzano in quale BC vivrà l'interfaccia utente stessa?

eventuali linee guida su questa domanda con un esempio sarebbero grandi ...

+0

come hai organizzato il codice sorgente alla fine? Hai avuto un'app Web per tutti i contesti limitati o un'app Web per contesto respinto? Se quest'ultimo, hai usato le aree in PVC? +1. – w0051977

risposta

5

Non sono un esperto, ma credo che l'interfaccia utente non vive in un aC. L'interfaccia utente è un'espressione di uno o più BC. Il BC è un limite attorno alle decisioni che sono collegate. Il modo in cui lo affili all'utente non è preoccupante.

Quindi, ad esempio, si dispone di una pagina Web, come ad esempio amazon.com con diverse BC, come si dice, l'interfaccia utente semplicemente ti guida insieme aiutandoti a prendere decisioni in qualsiasi BC con cui sei coinvolto.

Un ultimo tentativo. Se si immagina uno schema di un'architettura esagonale o di un'architettura a strati, si avrà al di fuori (in alto) una UI di qualche tipo. Comunicerebbe con un livello anti-corruzione (o servizio applicativo). Questo A-C quindi delegherebbe al BC appropriato per gestire il comando che volevi soddisfare.

+0

Sì, questa è una nuova linea di pensiero per me :), beh se dicessimo che ogni BC era un repository in Github o qualsiasi VCS, quindi dove si troverebbe fisicamente il codice dell'interfaccia utente? – Sudarshan

+0

beh, prima di tutto vorrei sconsigliare la segregazione o la distribuzione prematura. Se il tuo sistema ha bisogno di questo, allora è grandioso, ma se non lo stai aggiungendo alla complessità senza motivo, aggiungerai quelle funzionalità quando se ne presenterà la necessità. In secondo luogo, io uso .net, potresti avere un repository che contiene solo la tua app web e mantiene una connessione alle BC attraverso messaggi o ref diretti dll, oppure se hai tutti i progetti in un repository puoi includere i progetti di cui hai bisogno nella tua app web. – Raif

+0

Pensato a questo, tuttavia ciò significherebbe che tutte le viste si trovano all'interno della webapp e che i repository che fanno riferimento a ciascuna di queste BC non avrebbero alcuna rappresentazione UI (viste). Vorrei che questi BC fossero offerti come software indipendenti e quindi desideriamo che le viste relative a ciascuna delle BC risiedano nel repository BC stesso – Sudarshan

3

L'interfaccia utente ha le proprie preoccupazioni e modelli di collaborazione; è un BC a sé stante.

+1

Un BC è più di un termine DDD a livello concettuale, probabilmente l'ho usato nel contesto sbagliato ... Sto cercando di capire come dividere il codice sorgente basato su BC ... Penso che in molti casi abbia un repository per BC è un accordo equo. Da lì sto cercando di capire dove le UI che compongono le informazioni da più BC dovrebbero ... – Sudarshan

Problemi correlati