Cosa devo considerare durante l'architettura di un'applicazione modulare accoppiata liberamente?

0

Introduzione

Per un po 'di background, sto cercando di architettare un'applicazione per il mio avvio. La mia applicazione è divisa in 3 progetti separati di git, i dettagli sono i seguenti.

  1. API di backend scritta usando Flask, RESTful, Python 2.7.
  2. Server di autenticazione scritto usando Flask, RESTful, Python 2.7.
  3. Frontend scritto usando React 15, Redux, Node, Twitter Bootstrap.
  4. MySQL per database.

Cosa ho ottenuto

Sto utilizzando l'approccio MVC per costruire l'applicazione e la mia struttura dell'applicazione è la seguente.

La cartella principale è divisa in src (dove sono tutti i file sorgente), config.py, requirements.txt (dove sono presenti tutti i requisiti di terze parti), qualche altra configurazione.

La cartella Src è divisa in controller dove ho inserito tutta la logica dell'applicazione. Cartella del database in cui sono presenti tutti i modelli, i file di migrazione e di seed. Cartella API in cui è implementata l'API RESTFul, routes.py in cui sono presenti tutti gli endpoint della mia API.

I controller sono ulteriormente suddivisi in controller di sistema (in cui risiedono i moduli principali del mio sistema, ad esempio modulo di memorizzazione nella cache, modulo di registrazione). controller di modulo (dove risiederanno tutti i moduli che io o le persone in azienda svilupperanno, ad esempio il modulo di analisi e utilizzeranno i controller di sistema per integrarsi con il sistema) e i controller API (dove tutti i moduli che prenderanno informazioni dalle richieste in arrivo e elaborarli utilizzando i controller del modulo risiederà).

Ho scritto tutti i modelli riguardanti tutti i moduli da aggiungere o già presenti nella tabella del database.

Motivi per cui hai scelto questa struttura.

Mi piace l'idea di mettere cose simili che svolgono compiti simili in un unico posto, ad es. tutti i controller in una cartella, tutti i modelli in un unico posto.

Come farò a rendere il progetto sviluppabile per i miei sviluppatori ??

Inizialmente avevo l'idea di lasciare che i miei sviluppatori controllassero l'intero sistema sul loro PC, quindi permettessero loro di utilizzare i controller di sistema per fare cose come cache o logging ecc. e scrivere i relativi modelli nella cartella dei modelli all'interno della cartella del database.

Problemi che sto scoprendo con questo approccio

Per evitare che il nostro codice legacy si estenda o lasci che i nostri sviluppatori si sviluppino senza controllare l'intero sistema (che probabilmente diventerà gigantesco in futuro) il mio approccio fallisce.

Se provo a diventare modulare e consento agli sviluppatori di posizionare il codice basato su pattern MVC in un singolo pacchetto, quindi importare quel pacchetto nel sistema principale in produzione, ottengo i seguenti problemi.

  1. In che modo i miei sviluppatori codificano se hanno bisogno di una dipendenza a livello di sistema e hanno accesso solo al proprio pacchetto?
  2. Che cosa succederà se progettano un modello per il loro pacchetto e ha qualche dipendenza come le relazioni ad altre tabelle?
  3. Ci sono pacchetti comuni tra i miei 2 codebase separati e questo approccio mi sta facendo fare lo stesso cambiamento su 2 diversi posti che è una cattiva pratica.

C'era un'altra soluzione per consentire loro di importare l'intero sistema e nascondere i file importanti usando .pyc invece di .py. Ma a causa dell'intero meccanismo di importazione del modulo nelle modifiche python che non desidero.

E soprattutto non è in alcun modo univoco.

Conclusione

Sto lavorando e architettando un'applicazione distribuita per la prima volta nella mia vita e sono davvero impressionato dal modo in cui Laravel e il suo sistema di facciata sono modulari. Ho bisogno di consigli su come posso aggirare questi problemi e il mio approccio attuale è buono?

    
posta Anfal 18.11.2016 - 10:06
fonte

0 risposte

Leggi altre domande sui tag