Architetture a strati e software modulare

A different approach would obviously be to develop a more "componentized" application, where each business functionality is achieved through an independent module. Am I right in considering a layered architecture better, at least in containing the total cost of ownership and development of the application?

Se i tuoi "moduli indipendenti" o sezioni verticali hanno ciascuno i loro livelli (ad esempio per dati, business, gui) ottenere il beneficio dell'indipendenza senza perdere i vantaggi di un architekture a strati.

In uno shop online potresti avere fette per cliente, prodotto, disponibilità del prodotto, pricalcalcolo, ordine, pagamento, permessi, ....

Tuttavia potrebbe essere difficile rendere le sezioni indipendenti l'una dall'altra: Esempio: il calcolo preliminare richiede informazioni su cliente, prodotto, disponibilità del prodotto

Dopo aver pensato a questa domanda, ho voluto condividere il mio punto di vista.

C'è una frase che mi ha ricordato qualcosa che un architetto anziano mi ha detto una volta.

Ecco la tua frase

I have built a server-side Java application of about 10k lines of code and on a code review a colleague made me notice that when developing a new business feature , I have to touch several files

Ecco ciò che il mio collega mi ha detto (più o meno)

I have reviwed your projects. Overall those you took forward alone and I have noticed that your code (sometimes) is hard to read. Not due to spagetti code but for so many components. Often it's too abstract. Sometimes what customer needs is as simple as a rigid web app. Not a spaceship from NASA.

Devo confessare che Fa male, ma era vero. Lo faccio tante volte. Over engineering

...

Non avresti forse reso la tua app troppo complicata? Intendo. Mantenere il design a strati. Saresti in grado di farlo più facilmente? Potresti averne fatto troppi, Servizio, Reposizioni, configurazioni, componenti ... C'è una finestra per migliorare o semplificare quello che ora sembra troppo lavoro . Potresti provare a farlo troppo astratto.

Come ho detto sui commenti, non so a cosa serve la tua app, quindi spero che nessuno mi punisca per quello che ho appena detto.

Soluzione "Componente" o non attuale. Choice (IMO) si basa sulla natura e sugli obiettivi dell'app. Ne hai bisogno? È questo il modo in cui la tua app deve essere scalata? Tramite moduli, plugin, componenti aggiuntivi ..?

Che cosa stai costruendo? Un quadro? Un lenguaje? Un prodotto che consentirà alle terze parti / comunità di sviluppare i propri moduli o widget? Il prodotto principale dell'azienda?

Oppure è una soluzione semplice per uno specifico problema / esigenza che è stata fatta con alcuni minimi di qualità?

Non c'è design che ti impedisca di avere lavoro da fare quando sono necessarie nuove funzionalità. Alcune richieste tenteranno direttamente contro il buonsenso che il tuo design cerca di portare alla follia / caos che a volte affligge i clienti.

Riassumendo. Penso che i tuoi argomenti siano validi come qualsiasi altro in Pro del design modulare. Non appena funziona per te e fai ciò che è previsto, va bene.

Ciò che conta e ciò che può farti cambiare idea è che non vengono raggiunti né i requisiti né gli obiettivi.

Non ho risposto alla lista pro e contro di ciascun approccio, perché è qualcosa di facile da trovare su Google un po '.

Spero che ti sarà d'aiuto.