Sto pensando di adottare l'architettura pulita. la cosa principale in questa architettura, a quanto ho capito, è il flusso delle dipendenze da cima a fondo. quindi la prima cosa che mi sono chiesto è quale sarebbe il costo per cambiare i livelli inferiori (cioè le Entità)? questo strato avrà molte dipendenze e cambiandolo dovrò cambiare tutti i livelli fino alla cima. Ho ragione o mi manca qualcosa?
Hai ragione!
Se modifichi uno qualsiasi degli "oggetti business", ci sono molte modifiche secondarie nel codice, molto probabilmente anche in pacchetti diversi.
In questo articolo faccio esattamente questo esperimento con il progetto github di studio di architettura pulita / codice pulito di Uncle Bob: link
Risultato : in questo progetto estremamente banale , ho dovuto modificare 5 classi (50% di applicazione) per aggiungere un singolo campo dati indipendente. Questo sarebbe molto peggio (anche potenzialmente in modo esponenziale) in un'applicazione più grande.
Ecco un altro articolo che analizza, tra le altre cose, questa natura apparentemente non mantenibile di questo stile di architettura: link
Conclusione : la "Clean Architecture" può adattarsi a progetti in cui la parte "business" non cambia mai o raramente mentre le tecnologie cambiano molto. È ottimizzato per cambiando stack tecnologici. Non sono sicuro del progetto che desidera invece di funzioni aziendali.
Pensa nell'architettura pulita né di livelli né di posizioni come sopra o sotto. È fondamentale pensare a (forse) anelli o gusci che possono essere usati dagli anelli esterni e proteggere gli anelli interni.
L'anello più interno dovrebbe sempre essere il tuo dominio e quindi non è in grado di avere dipendenze da nessun altro anello che lo circonda. In parole povere questo significa che il tuo dominio è privo di aspetti tecnici o applicativi specifici. Quindi le tue entità sono fatte bene, se dipendono solo da altri componenti nel tuo dominio.
Forse ti chiedi ora, come mai comunicare con l'infrastruttura, diciamo un database, se non posso avere una dipendenza da questo. E qui, come dice il bardo, si nasconde lo sfregio. Definisci semplicemente un'interfaccia nel tuo dominio che descrive un concetto di comportamento di cui hai bisogno. In questo caso, come conservare la tua entità. Ma non hai un'implementazione concreta nel tuo dominio. E non ne hai bisogno, perché le interfacce sono astrazioni per concetti generali. Quanto esattamente la tua entità è archiviata, non è una preoccupazione per il tuo dominio.
L'implementazione si trova in un anello esterno. Principalmente nell'anello più esterno, a volte chiamato ring dell'infrastruttura.
Con il tuo metodo principale (l'applicazione) puoi creare un'implementazione adatta e assegnarla al tuo dominio. Questo è spesso fatto da un meccanismo di iniezione di dipendenza.
Quindi alla fine non c'è nulla di mistico. Il tuo dominio definisce ciò di cui ha bisogno dai livelli esterni in un modo aziendale e gli anelli esterni li implementano e li collegano.
Per ulteriori letture, consiglierei l'articolo di Uncle Bob Martin sull'architettura pulita in uno dei tanti siti che lo hanno pubblicato:
Leggi altre domande sui tag architecture