> 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/regole-operative.md). # Regole operative Un sistema è suddiviso in regole operative e plugin. Ma che cosa sono le regole operative? In senso stretto, **le regole operative sono regole o procedure che permettono di creare o risparmiare denaro**. Esse esisterebbero a prescindere, anche se ad applicarle non ci fosse un computer. Per esempio, la banca che addebita una percentuale di interessi per un prestito è una regola operativa che permette alla banca di accumulare denaro. Questa regola esisterebbe a prescindere, non importa se a calcolare gli interessi sia un computer o un impiegato. Questo tipo di regole vengono definite **regole operative critiche**. Le regole operative critiche, solitamente, richiedono dei dati da elaborare. Nel nostro esempio, un prestito richiederebbe: una somma, un tasso di interesse e un piano di rimborso. Questi dati vengono definiti **dati operativi critici**. Le regole operative critiche e i dati operativi critici possono formare un oggetto, che chiameremo **entità**. ### Entità Un'entità è un oggetto, il quale contiene i dati operativi critici (o comunque ha accesso diretto ad essi) e delle funzioni che implementano le regole operative critiche che operano su tali dati. L'entità seguente rappresenta un prestito: ![](/files/-M-R0uq9zZzyZu6ilSo7) Essa è ignara dei dettagli relativi al database, all'interfaccia utente e al framework utilizzato. Può svolgere i propri compiti in qualsiasi sistema, indipendentemente dai dettagli presenti nell'applicazione. ### Casi d'uso Alcune regole operative permettono all'azienda di creare o risparmiare denaro definendo il modo in cui può operare un **sistema automatizzato**. Prendendo l'esempio precedente, immaginate che la banca decida che gli addetti ai prestiti, prima di stimare l'importo, devono raccogliere le informazioni sul cliente e assicurarsi che la solvibilità del richiedente sia maggiore di 500. Se non eseguono tutti questi passaggi non possono accedere alla schermata di prestito. Questo è un **caso d'uso**, ovvero una descrizione del modo in cui deve essere utilizzato un sistema. **Un caso d'uso specifica le regole operative dell'applicazione, non le regole operative critiche delle entità**. Notate questo esempio di caso d'uso: ![](/files/-M-R5Tx6xRELz1vzQA_G) Notate come nell'ultima riga si fa riferimento all'entità *Cliente*. I casi d'uso interagiscono con i dati e le funzioni contenute nelle entità. Le entità (alto livello) non sono a conoscenza dei casi d'uso (basso livello) che le controllano. I casi d'uso si trovano ad un livello inferiore rispetto alle entità perché sono specifici dell'applicazione e sono più vicini agli input e agli output del sistema. Le entità sono generalizzazioni che possono essere usate anche in altre applicazioni, pertanto sono più lontane dagli input e dagli output del sistema. Infine, i casi d'uso, così come le entità, devono essere indipendenti dal tipo di interfaccia utente e dal tipo di database utilizzato. ### Modelli a richiesta e risposta La classe del caso d'uso accetta in input delle semplici strutture di dati di richiesta (DTO) e restituisce in output delle semplici strutture di dati di risposta. Queste strutture di dati **NON** devono dipendere da interfacce standard del framework, come *HttpRequest* o *HttpResponse*. Se queste strutture di dati non fossero indipendenti, allora i casi d'uso si troverebbero legati all'interfaccia Web. Altra cosa da evitare è quella di far contenere a queste strutture dati i riferimenti alle entità. Gli scopi di questi due oggetti sono molto differenti. Nel corso del tempo essi cambieranno per motivi o in momenti molto differenti. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://mirkorap16.gitbook.io/clean-architecture/regole-operative.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.