Quando separare i dubbi relativi alle applicazioni

Question

Quando separare i dubbi relativi alle applicazioni

#1 da (1 voti)
#2 da (1 voti)

1

Ho lavorato per un certo numero di aziende che, nel tempo, hanno ramificato il loro servizio principale per fornire servizi aggiuntivi e / o flussi di entrate. La mia domanda è quando è il momento giusto per separare queste preoccupazioni in più applicazioni, anche quando funzionano sugli stessi dati / estensioni di alcuni?

Ad esempio, supponiamo che un'azienda abbia un'applicazione di business principale che si risolve attorno all'indice musicale / alla scoperta della musica. Se questa società in seguito ha deciso di espandersi nell'offerta di siti Web per musicisti che utilizzano l'indice esistente, dovrebbe essere un'applicazione separata che riceve i dati dall'applicazione core-business tramite API o è ragionevole inserirlo in un modulo di l'applicazione esistente e usa gli oggetti aziendali esistenti?

Mi sembra che la abilità di raggruppare le cose in un'unica applicazione non dovrebbe essere una ragione sufficiente per farlo. In Unix, pratichiamo Separation of Concerns, ma quando si tratta di sviluppo aziendale, questo principio sembra essere perso. Nell'esempio sopra, ritengo che questi dovrebbero essere applicazioni separate, ma nella mia esperienza sono testimone che gli sviluppatori li sommano tutti insieme per risparmiare tempo.

design

posta Craige 16.03.2013 - 01:32

fonte

2 risposte

Leggi altre domande sui tag design

Generatore di mappe del corso È una cattiva pratica creare istanze da una query SQL?

score 1 · Answer 1

Penso che si riduca a stabilire se sia o meno opportuno raggruppare la funzionalità come addon / extension o se dovrebbe essere autonoma a se stante. Nel tuo esempio, sarebbe più sensato per me esporre i dati rilevanti in un modo SOA per i siti web dei musicisti piuttosto che collegarli all'applicazione principale in quanto non vi sono praticamente sovrapposizioni diverse dai dati. La logica pertinente verrebbe incapsulata nei servizi.

In generale, ritengo che praticare una separazione delle preoccupazioni sia la soluzione migliore, modularizzando le applicazioni e riutilizzando il codice laddove possibile. Un ottimo esempio di ciò sarebbe Microsoft Office, che sfrutta un'interfaccia (abbastanza) coerente fornita da varie librerie condivise, correttori ortografici condivisi, VBA e altro ancora implementando la propria logica e interfaccia core.

score 1 · Answer 2

Il momento giusto è ora, a meno che tu non abbia altri requisiti da soddisfare. Più gli strati della tua applicazione sono separati, più sarà flessibile adattarsi alle mutevoli esigenze. Se ha senso implementare un livello come API o come servizio dipende dai tuoi requisiti.

Non riesco a indovinare il motivo per cui più sviluppatori non prendono sul serio il principio di Separazione dei dubbi. Forse non vedono i benefici a lungo soppesando la necessità di finire il lavoro ora.