Quale dovrebbe controllare la progettazione del software applicativo, Lingua o Quadro o Dominio? [chiuso]

Question

Quale dovrebbe controllare la progettazione del software applicativo, Lingua o Quadro o Dominio? [chiuso]

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

-3

Recentemente ho cercato di approfondire la parte di progettazione dei programmi applicativi. Il suggerimento sembra essere molto diverso tra diverse fonti. Ad esempio i libri come il codice completo suggeriscono di costruire in linguaggio o framework. Un altro approccio come clean suggerirà un approccio più aziendale o orientato al dominio.

Quale sarà l'approccio che può dare a noi stessi un vantaggio competitivo su una base a lungo termine? Soprattutto mi piacerebbe sapere come si applica allo sviluppo di app per dispositivi mobili.

design design-patterns application-design

posta Arun C 25.03.2017 - 17:21

fonte

2 risposte

Leggi altre domande sui tag design design-patterns application-design

Qual è il modo migliore per sviluppare la GUI per l'applicazione scritta in C e aggiungere anche funzionalità di rete al suo interno? In che modo il mio computer associa una sequenza di tasti a un numero di pixel corrispondente alla lettera di battitura sullo schermo? [chiuso]

score 2 · Answer 1

Opzione 4: Nessuna delle precedenti.

Il consiglio di "costruire in una lingua / struttura" è ortogonale alla DDD - dovresti fare entrambe le cose; questa non è una o / o situazione. Il software ben progettato dovrebbe essere modulare con una separazione netta tra gli strati; in questo modo puoi ottenere entrambi.

I moduli di interfaccia utente di primo livello non dovrebbero preoccuparsi di gestire la logica aziendale o la logica di dominio; dovrebbero concentrarsi sul fornire un flusso di lavoro e UX ottimali: il design deve essere informato dalle best practice del framework UI insieme ai pattern di progettazione dell'interfaccia utente comuni come MVC / MVVM / MVP / etc.

I moduli del livello di dominio non dovrebbero sapere nulla sull'interfaccia utente o sulla UX, ma si concentrano invece sulla logica aziendale: la sua progettazione dovrebbe essere guidata dai requisiti del dominio.

Pulisci la separazione tra il tuo livello di interfaccia utente / app e il tuo livello aziendale / dominio implica un'interfaccia (s) che separa i due; non c'è alcun motivo per cui la progettazione di un'interfaccia utente influisce sul modello di dominio o sulla logica aziendale e l'implementazione della logica aziendale non ha motivo di influenzare o limitare la progettazione o l'implementazione di un'interfaccia utente.

Inoltre, non vi è alcun motivo per cui l'interfaccia utente dovrebbe persino utilizzare lo stesso linguaggio di programmazione del livello di dominio, ad esempio un'interfaccia utente che utilizza HTML + ECMAScript e un livello aziendale utilizzando una tecnologia lato server come ASP.NET o Ruby su Rails; nel qual caso ci sarà una minima sovrapposizione tra i due oltre all'interfaccia REST.

score 0 · Answer 2

Nonostante tutta la teoria pulita, in genere alcune scelte architettoniche precedono le scelte progettuali fatte nel contesto di un particolare progetto o applicazione. Ciò significa che dovrai gestire una serie di dati che potrebbero non essere necessariamente la scelta migliore per il progetto / applicazione che stai costruendo. Pensa a un RDBMS, a un sistema operativo, a un particolare linguaggio di programmazione.

Questi strumenti di base sono stati progettati per un particolare (intervallo di) domini problematici. Finché sviluppi soluzioni all'interno dei domini target degli strumenti, ti aiuteranno con i modelli predefiniti.

Quindi, in ogni ambiente, alcuni modelli di progettazione verranno sistemati in anticipo. Man mano che le scelte architetturali fatte una volta diventano obsolete e / o il business si evolve, potresti iniziare a sperimentare un po 'di stress nella tua esperienza di modellazione. Potresti voler fare le cose in un modo mentre i tuoi strumenti insistono per fare le cose in un altro modo.