In Clean Architecture, non sono entità un altro tipo di limite?

Question

In Clean Architecture, non sono entità un altro tipo di limite?

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

2

Nell'architettura pulita, lo zio Bob definisce Entità come regole aziendali e Interact (casi d'uso) a livello aziendale come regole aziendali specifiche dell'applicazione. Inoltre, descrive che gli Interactor sono responsabili della "danza delle entità", e nei diagrammi dell'interazione - > La relazione di entità viene mostrata come diretta, senza limiti.

Quello che non sembra capire è che per testare un Interactor, testerei inavvertitamente il codice dall'Entity, poiché sembrano essere accoppiati insieme.

Ci sono alcuni progetti che implementano l'architettura pulita che non contiene la logica all'interno delle entità, solo i dati.

Quindi, dovrebbero Entities:

conserva solo dati,
essere un altro limite o
essere testato con gli Interactiani o
qualcos'altro?

clean-architecture

posta Fernando Toigo 18.12.2018 - 14:03

fonte

2 risposte

Leggi altre domande sui tag clean-architecture

Sezione Background & Research Methods (Scrivere un articolo) Come posso gestire i messaggi chat in modo asincrono?

score 1 · Answer 1

Se detieni solo dati nel tuo Entities , il tuo modello di dominio diventerà anemico , perché il l'incapsulamento è rotto e i comportamenti sono tutti definiti al di fuori dell'entità, lontano da dove sono dichiarati i dati.

L'intero punto dell'architettura pulita (e dell'architettura esagonale, dell'architettura della cipolla, ecc.) è quello di promuovere il principio di inversione delle dipendenze, il D nell'acronimo SOLID . Per fare ciò, gli strati esterni devono dipendere dagli strati interni, non dall'opposto. Ecco perché non è solo ok ma è necessario che i tuoi interlocutori dipendano dalle tue entità. Ma le tue entità non dovrebbero dipendere dai tuoi interlocutori.

Testare gli interattori significa testare un intero caso d'uso, quindi è totalmente pensato per eseguire il codice nelle tue entità!

score 0 · Answer 2

I modelli architettonici non sono pensati per essere seguiti religiosamente. Come ogni altro modello nel software, sono soluzioni ben collaudate e definite per problemi specifici, ma abbastanza flessibili da adattarsi. Rispondere alle tue domande:

So, should Entities:

hold only data,

Dipende dal tuo dominio. A volte, hai bisogno di Entità in grado di trasformare o aggiornare il loro stato. D'altra parte, potrebbe essere necessaria una rappresentazione dei dati di un dato concetto, senza alcun stato (e.x .: classi di dati in Kotlin). Su Android, ad esempio, è piuttosto comune avere un modello anemico, e questo è OK perché si adatta al dominio il più delle volte.

be another Boundary

Di nuovo, dipende dal tuo dominio. Gli interactor fungono già da confine tra le Entità e il resto del tuo sistema e, se non hai bisogno di riutilizzare le tue Entità in nessun'altra parte al di fuori della tua applicazione, non hai bisogno dello sforzo e / o della complessità aggiuntivi necessari per isolarli (supponendo che che il loro stato, se esistente, è ben incapsulato). Non aggiungere complessità in cui non ti serve :)

be tested with the Interactors

Lo indovini - dipende dal tuo dominio. Se hai un codice specifico nelle tue Entità che vuoi assicurarti che funzioni, certo, lo collaudi. Tuttavia, non dovresti astenervi dal collaudare i tuoi Interact con le tue Entità perché 1) i test di integrazione sono belli, 2) gli interattori sono piuttosto inutili se non funzionano bene con le tue Entità, quindi potresti anche assicurarti che e 3 ) dato che probabilmente prenderai in giro repository e mapper, avrai una buona sensazione di quanto sia robusto l'intero livello di dominio.

Per farla breve, se comprendi il contesto del problema che stai risolvendo, non devi preoccuparti più di tanto di come applichi un'architettura pulita. Usalo come guida, naturalmente, ma fallo in un modo che ti sembra giusto o adatto a te, apprendi da esso e rifattalo in seguito, se necessario.