> For the complete documentation index, see [llms.txt](https://mirkorap16.gitbook.io/clean-architecture/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mirkorap16.gitbook.io/clean-architecture/delimitazioni-parziali.md).

# Delimitazioni parziali

Le delimitazioni complete dell'architettura sono costose. Isolare completamente due componenti per renderli indipendenti richiede molto lavoro. Un buon architetto deve saper analizzare la situazione e decidere se implementare una delimitazione completa o parziale.

### Delimitazioni monodimensionali

Una delimitazione completa dell'architettura impiega delle interfacce di delimitazione reciproche per garantire l'isolamento dei componenti in entrambe le direzioni. Avere questo tipo di separazione in entrambe le direzioni è costoso in termini di lavoro. Una delimitazione parziale, in molte situazioni, è più che sufficiente.

![](/files/-M-eE8l6dfZtyGfdlyfz)

L'interfaccia *Service* viene usata da *Client* e implementata da *ServiceImpl*. L'inversione della dipendenza è presente per separare *Client* da *ServiceImpl*. Tuttavia, nulla impedisce a *ServiceImpl* di utilizzare *Client* (come mostrato dalle linee tratteggiate). Questa è una tipica **delimitazione monodimensionale**.

### Facade

Un altro esempio di delimitazione parziale è rappresentato dall'utilizzo del pattern **Facade**.

![](/files/-M-eFlUh_ZFibJiSjrjk)

In questo esempio anche l'inversione della dipendenza viene sacrificata. La delimitazione è definita semplicemente dalla classe *Facade*, la quale fornisce dei metodi per richiamare dei servizi ai quali il client non deve poter accedere direttamente.

### Conclusioni

Abbiamo visto solo alcuni esempi di come poter creare una delimitazione parziale. Sta all'architetto capire dove potrebbe collocarsi, un domani, una delimitazione dell'architettura e se implementare pazialmente o integralmente tale delimitazione.