Come garantire la separazione e le dipendenze interne tra i livelli architetturali in Python?

Question

Come garantire la separazione e le dipendenze interne tra i livelli architetturali in Python?

#1 da (1 voti)

-1

Supponiamo che un progetto su larga scala sia in via di sviluppo in Python 3.7. Viene scelta una architettura stratificata: "architettura pulita", "cipolla" o "esagonale". La regola della dipendenza in esso consente solo le dipendenze dall'aspetto interno; link .

In alcune lingue questa regola è supportata da strumenti di compilazione (ad es. gradle, maven o sbt), che definiscono le dipendenze esplicite tra i sottoprogetti; ad esempio, link . Questo, tuttavia, non sembra possibile in Python 3. Le uniche soluzioni che ho trovato, come un progetto Python separato o un microservice per livello, sembrano eccessivamente complicate.

Specificamente, supponiamo che il livello Applicazione possa dipendere dal livello Dominio , ma non viceversa.

Domande:

Quale può essere una soluzione in Python 3.7 per mantenere questa struttura di dipendenza?
In che modo i moduli in Dominio non sono tecnicamente autorizzati per l'importazione da moduli

Extra: La mia soluzione attuale è di emulare i sottoprogetti definendo i pacchetti di livello superiore APP e DOMAIN. Questa capitalizzazione funge da contrassegno nelle istruzioni di importazione.

design clean-code architecture python

posta Tupolev._ 14.11.2018 - 15:44

fonte

1 risposta

Leggi altre domande sui tag design clean-code architecture python

Dovremmo inserire casi speciali in business logic / algoritmi o lasciarli separati? [chiuso] Struttura delle cartelle per un progetto C [chiuso]

score 1 · Accepted Answer

L'utilizzo di progetti separati sarebbe l'unico modo per applicare questa separazione, ma potrebbe essere sufficiente semplicemente guidare il programmatore lontano da dipendenze non volute.

Python qui ha il problema che è un linguaggio dinamico: puoi dipendere da un'interfaccia senza mai menzionarla, dato che tutto è digitato anatra.

Le possibili strategie includono:

fare molta attenzione a eseguire l'iniezione delle dipendenze piuttosto che import ing funzionalità, e quindi testare il codice sostituendo i livelli esterni con mock e driver di test. Questo avverrà in modo naturale se stai cercando di seguire un approccio BDD-ish.
rendendo esplicite le interfacce implicite, iniziando a usare le annotazioni di tipo con un controllo di tipo come MyPy. È quindi possibile scrivere i file stub per le interfacce esterne e il correttore di tipi dovrebbe presentare un reclamo se si verifica una dipendenza da funzionalità non menzionate nell'interfaccia. Sfortunatamente, annotare il codice sorgente a un livello in cui il correttore di tipi può funzionare bene richiede un grande sforzo, soprattutto perché molte variabili avranno il tipo Any che non è soggetto a ulteriori verifiche.