Organizzazione per funzione aziendale rispetto a funzione tecnica

4

Sto progettando una grande applicazione (un analizzatore di codice statico) e ho una scelta su come organizzare il codice in moduli:

  • Un approccio è quello che chiamerei per funzione tecnica . Qui è dove hai un pacchetto per gli oggetti dati, un altro per funzioni di servizio, viste, controller, ecc.

  • Un altro approccio è quello che chiamerei funzione aziendale . Questo in cui avresti un pacchetto per, diciamo, controllo delle scorte, un altro per le schede di prodotto, gli ordini dei clienti, ecc.

La maggior parte dei framework tende a spingermi verso il primo approccio. A volte ci sono motivi tecnici per questo, ad es. se la vista è scritta in JavaScript e il resto in Python, devi davvero tenerlo separato. Ma soprattutto è solo una questione di convenzione.

A volte l'organizzazione per funzione tecnica si traduce nella diffusione del codice correlato attraverso l'applicazione. Se ho il codice per supportare un prodotto, finisco con ProductModel, ProductService, ProductView, ecc. Spesso sento che sarebbe più semplice avere semplicemente un oggetto Product che faccia tutto questo.

Anche l'organizzazione per funzione aziendale ha dei problemi. Alcune classi sono borderline ed è abbastanza arbitrario quale pacchetto le metti. E ci sono alcuni oggetti di supporto che sono usati in tutte le funzioni aziendali.

Quale approccio sarà più efficace per creare un'applicazione scalabile e manutenibile?

    
posta paj28 07.03.2014 - 14:53
fonte

1 risposta

3

Di solito organizzo per "funzione aziendale" (dominio problematico). Se stai cercando di utilizzare oggetti per rappresentare relazioni tra "cose" nel "mondo reale", quindi "Prodotti", "Ordini", ecc., Più direttamente mappare a ciò che l'utente conosce (la lingua del dominio) e dovrebbe essere più intuitivo per te per discutere, scrivere e mantenere.

Ci saranno sempre preoccupazioni trasversali. Esempi semplici sarebbero eccezioni, registrazione e connessioni al database. Solitamente puoi estrarre quei "servizi" per gli oggetti o le interfacce.

In sostanza si finiscono con due tipi di classi: oggetti specifici del dominio (prodotti, ordini) e oggetti trasversali (eccezioni, persistenza, viste dati). Non so se questa è la best practice ufficiale, ma è possibile vedere un concetto simile nell'organizzazione framework .NET. Oggetti specifici del dominio sarebbero come stringhe, adattatori dati, ecc. Gli oggetti e le interfacce trasversali sarebbero come IEnumerable o Exceptions.

    
risposta data 07.03.2014 - 18:26
fonte

Leggi altre domande sui tag