Decidere come dividere l'architettura usando i blocchi

3

Ho difficoltà a decidere il modo migliore per gestire la suddivisione in caso di verifica dei blocchi per architetture diverse. Potrei gestire lo scenario in modo completamente sbagliato, quindi fammi sapere se è il caso o se è un duplicato.

Come semplice esempio, supponiamo di avere due parametri da considerare per uno script Web: stato membro (non membro, tipo membro-A, tipo-B, tipo-C) e invio modulo / invio non formale. I moduli possono essere presentati da entrambi i membri e non membri. Attualmente, lo script sarebbe idealmente diviso in quanto tale:

Members (A, B, C)
    ->Non-Forms
    ->Forms
Non-Members
    ->Non-Forms
    ->Forms


... tuttavia, potrebbe essere impostato nell'altro modo:

Forms
    ->Members
    ->Non-Members
Non-Forms
    ->Members
    ->Non-Members

Suppongo che questo sia un caso specifico, quindi ci saranno delle considerazioni sul perché potresti o meno voler elaborare i moduli prima di altre attività, ecc. Tuttavia, sto cercando i criteri generali per decidere la divisione di tale architettura schemi in futuro, non considerando il caso speciale con considerazioni ovvie, in modo che io possa capirlo da solo. (Nota: la sicurezza è, ovviamente, una preoccupazione in questa situazione, quindi c'è una buona causa per un membro e funzionalità non membro, che è qualcosa che potrei considerare come una "considerazione ovvia". Se hai qualcosa che vuoi aggiungere per questo caso, però, sarò tutto d'occhio.)

    
posta user58446 02.01.2015 - 12:34
fonte

1 risposta

1

Il modo migliore per progettare il software per questa istanza sarebbe farlo con un approccio basato sul modello di dominio. Progetta in modo essenziale il tuo modello di dominio e le relazioni tra entità nel tuo modello di dominio. Persistenza, eventi, logica aziendale, sicurezza, visualizzazione e logica del controller possono essere determinati dopo il fatto.

Esempio:

  • Invio: proprietà comuni tra Form e Non-Form
  • Persona ?: proprietà comuni tra membri e non membri
  • Modulo: Estendi invio, ha riferimento a una persona, proprietà di un modulo
  • Non-forma: estende l'invio, ha un riferimento a una persona, proprietà di non-forma
  • Membro: estende Persona, proprietà di un Membro
  • Non membro: estende persona, proprietà di un non membro

Ora che hai definito il tuo modello di dominio e le relazioni tra di loro, diventa il logico passo successivo per considerare altri aspetti del tuo design. Quali sono i comportamenti chiaramente definiti di un Non-Form su un modulo? Definisci questi comportamenti nel codice. Quale logica aziendale deve essere eseguita in caso di invio di un modulo? Codice. Ovviamente la sicurezza può essere incisa, si considerano comportamenti diversi tra un Membro e un Non Membro come parte della propria logica aziendale. Ovviamente non dimenticare di testare accuratamente tutti i comportamenti delle tue applicazioni.

La cosa più importante nella tua progettazione è DEFINE il tuo modello di dominio, solo allora se consideri i comportamenti.

    
risposta data 02.01.2015 - 13:50
fonte

Leggi altre domande sui tag