quali sono le regole di progettazione del layering sul lato server dell'applicazione Web e le best practice che desideri applicare?

Segue una risposta lunga e sconclusionata e non sto usando veramente la metà della terminologia formale che dovrei essere (ma va bene, perché qualcuno mi correggerà!):

No Golden Bullet

Inizierò dicendo che penso che ogni architettura software dovrebbe essere progettata per il problema in questione. Non esiste un proiettile d'oro, un martello d'argento o una soluzione adatta a tutti i casi.

Strategia generale

È a:

• Dissocia i tuoi componenti
• Codice alle interfacce
• In generale, pensa alla separazione delle preoccupazioni
• Pensa a chi chiama il tuo codice per quale scopo

Perché ci sono schemi?

I modelli di progettazione (e quindi i framework che li circondano) emergono perché risolvono determinati problemi comuni.

Tuttavia, un errore che penso che molti sviluppatori Java siano colpevoli è di progettare architetture in eccesso, applicando i modelli a destra e al centro. Pensano a tutti i tipi di esotico "What If?" scenari. Il mio consiglio è che, sebbene esistano modelli comuni, non applicarli solo ciecamente, ma assicuratevi di avere un valido ragionamento per farlo.

Esempi

1.) Le persone hanno utilizzato MVC per anni perché ti danno la possibilità di cambiare il modello, la vista o il controller senza che si verifichino a vicenda (a meno che non lo desideri). Quindi per esempio se voglio:

• Cambia la mia tecnologia Visualizza da JSP a JSF Non dovrei cambiare il mio Modello
• Aggiungi un campo gambe al mio cane modello , non devo aggiungere automaticamente quel campo gambe al mio elenco di cani Visualizza , o cambia il mio Controller affinché un utente possa spostarsi dall'elenco di Cani Visualizza a una Vista di un cane dettagliata.

2.) Uno dei motivi per cui Servizi sono diventati popolari a causa dell'aumento di più clienti. Quindi, ad esempio, se voglio avere un client Java Swing e un client JSP che elencano entrambi i cani di grossa taglia nel sistema, possono chiamare lo stesso metodo DogShelterService List<Dog> getBigDogs();

Conclusione

Ci sono molti altri esempi di modelli e il motivo per cui sono venuti (sospetto che qualcuno fornirà esempi migliori di quello che ho fatto io). Trovo che l'utilizzo di un approccio BDD, TDD / ATDD (almeno nei termini del tuo pensiero) aiuti a chiarire il design e dove potresti voler andare per un modello formale di design e dove il semplice codice andrà bene.

how ... do you design your serverside application (in terms of layers) and what rules do you apply to them?

Utilizziamo Apache, Django e MySQL. Questo definisce i livelli.

What are the generally accepted justifications for these layers and these rules?

La giustificazione è "È così che funzionano Apache, Django e MySQL."

What rules do you see that should be considered 'bad practice'?

Il dogmatismo irragionevole è una cattiva pratica.

Lo sforzo speso cercando di "codificare" o "ridurre" l'architettura su poche regole è una cattiva pratica.

What rules do you considered essential?

L'architettura è difficile.

Segui il percorso più semplice che si adatta meglio al framework.

Il più delle volte i livelli e le regole utilizzate sono guidati dall'uso idiomatico delle librerie di base e delle tecnologie che hai scelto. Si spera che la scelta della tecnologia di base da utilizzare sia stata effettuata con analisi e lungimiranza. Occasionalmente devi sovvertire l'uso idiomatico, o anche la tecnologia di base per portare a termine il lavoro. Quelle occasioni dovrebbero essere rare perché l'uso non idiomatico è generalmente più costoso da mantenere.

Regole:

1. Scrivi il codice più semplice per implementare la soluzione migliore che puoi nel modo più tempestivo possibile.
2. Rimuovi pratiche e tecniche che rendono l'implementazione più lenta, più bacata e più complicata.
3. Aggiungi pratiche e tecniche che rendono l'implementazione più rapida, più manutenibile e più semplice.

Queste regole sono spesso la giustificazione per l'utilizzo di determinate architetture, tecnologie o pratiche. Il problema è che non ci sono pratiche applicabili in tutti i contesti di programmazione.

Regole errate:

1. Trattare qualsiasi pratica come sacrosanta.

Nessuna pratica ha valore in sé e per sé. Ha valore solo nella sua capacità di farti lavorare "meglio". Le persone spesso dimenticano questo e questo è il momento in cui ottieni aderenza dogmatica indipendentemente dal costo o dal beneficio.