CRUD è un acronimo che sta per Crea, Leggi, Aggiorna e Elimina. Quelle sono le quattro operazioni di base che è possibile eseguire su una tupla di database. Ma c'è sempre di più per le applicazioni aziendali che creare, leggere, aggiornare e cancellare i record del database.

Iniziamo con alcune definizioni di base, quindi esaminiamo un paio di esempi e vediamo come queste definizioni si associano agli esempi e come si mappano al software reale.

Logica aziendale o logica di dominio è quella parte del programma che codifica le regole aziendali reali che determinano il modo in cui i dati possono essere creati, visualizzati, archiviati e modificati. Prescrive come gli oggetti business interagiscono tra loro e impone i percorsi e i metodi con cui gli oggetti business sono accessibili e aggiornati.

Regole aziendali descrivono le operazioni, le definizioni e i vincoli che si applicano a un'organizzazione. Le operazioni collettivamente formano un processo; ogni azienda utilizza questi processi per formare sistemi che fanno funzionare le cose.

Ora, lavoriamo con alcuni esempi.

Trasferimento di denaro da un conto corrente a un altro

In primo luogo, quali sono le cose che devi sapere (input)?

• L'identità della persona che effettua il trasferimento
• La quantità di denaro da trasferire
• Il numero dell'account di controllo della fonte
• Il numero dell'account di controllo target

Quali sono alcune delle "regole aziendali" che devono essere applicate?

• La persona che effettua la richiesta deve avere l'autorità per farlo.
• La transazione deve essere atomica .
• La transazione potrebbe comportare requisiti di reporting per il governo, se è superiore a un determinato importo

Per "atomico", intendo che la transazione deve avere successo o deve fallire completamente. Non è possibile avere transazioni di conto in cui il denaro è prelevato da un account senza arrivare nell'altro (il denaro scompare), o il denaro è depositato in un conto, ma non addebitato da un altro account (il denaro appare magicamente dal nulla).

Ordinare qualcosa da Amazon.

Che cosa hai bisogno di sapere?

• L'identità della persona che ordina
• Informazioni sulla spedizione
• Dati di fatturazione
• Metodo di pagamento
• Quantità e quantità di ciascun articolo da spedire
• Come spedire (durante la notte, barca lenta o super risparmiatore)
• Aliquota fiscale dello Stato

Cosa succede dopo che l'ordine è stato piazzato?

• Gli articoli vengono estratti dallo stock
• Le quantità a disposizione sono addebitate
• Gli articoli sono confezionati per la spedizione
• Gli articoli esauriti sono in arretrato
• Gli articoli che scendono al di sotto delle quantità minime sono ordinati
• Una spedizione o due?

• Una fattura / lista di spedizione viene stampata e inserita con l'ordine

  .. etc.

CRUD è semplicemente Crea, Leggi, Aggiorna, Elimina un'applicazione.

In una certa misura, un bug tracker è anche un'app CRUD. Crea bug, leggi (mostra) i bug, aggiorna i bug e, forse, cancellali.

Tuttavia, c'è di più in un bug tracker che non solo CRUD.

• A uno sviluppatore non è consentito contrassegnare il bug verificato o chiuso - questa è una parte del lavoro di QA. E quindi c'è del codice per assicurarsi che qualcuno che non ha il ruolo di QA non possa contrassegnare un bug come chiuso o verificato.
• Nessuno tranne un project manager può effettivamente eliminare un bug.
• Affinché un bug sia contrassegnato come "test me", deve esserci almeno un commit di codice contro il bug.
• Solo un bug che si trova nello stato "chiuso" può essere spostato nello stato di "riapertura"
• Lo sviluppatore assegnato al bug non può spostarlo da 'revisione del codice' a 'revisione del codice completa'
• Il QA e gli sviluppatori possono vedere solo errori sui progetti a cui sono assegnati.

Il codice che implementa quanto sopra è la logica di business dell'applicazione.

La limitazione dei flussi di lavoro o chi può eseguire le varie operazioni in CRUD. Questi sono ciò che separa una app CRUD da un'altra. Sono le parti in cui è necessario convincere l'azienda a dire in realtà come funziona l'applicazione. Com'è logico ... beh, questo è il modo migliore di discuterne con una birra lontana dalla portata del project manager. Ma questa è la logica aziendale.

Certo, è possibile scrivere un'app CRUD "pura" dove non ci sono ruoli, tutto può essere modificato e visualizzato - ma questi sono l'eccezione piuttosto che la regola.

La logica aziendale è la logica che stai scrivendo nel tuo programma per gestire le regole aziendali che ti vengono fornite.

Quando inizi a entrare in regole di business, questo tende ad essere ad un livello più alto di quello stesso o di logica aziendale. Questo tende ad essere quello che ottieni da un analista di business che sta lavorando con il business.

Considera in questo esempio, un programma che determina come gestire la restituzione di un articolo presso un banco resi in un negozio.

• Se la ricevuta è uguale o superiore a 90 giorni, si può dare solo credito in negozio
• Se la ricevuta ha meno di 90 giorni, accredita l'offerta con cui è stata utilizzata la ricevuta (il credito ritorna sulla carta di credito, il contante ritorna in contanti, il credito in negozio va al credito in negozio). a meno che non si tratti di un assegno, nel qual caso utilizzare denaro contante.

Queste sono alcune regole aziendali. Non parlano alla parte CRUD dell'applicazione.

Quando lavori con le regole aziendali, potresti trovarle spesso in un motore delle regole (ad esempio, Motore regole Windows Workflow Foundation ) anziché scrivere il codice raw nel sistema.

Comprendi che la distinzione logiche / regole è terminologica e può essere discussa per tutta la notte (meglio ancora su una birra). Anche se questa non è una distinzione rara, anche se i due possono fondersi l'uno nell'altro.

Altre risposte sono corrette. Un ulteriore pensiero ...

La logica aziendale è portatile

Se dovessi reimplementare un progetto software in un linguaggio di programmazione diverso, ad esempio spostando da Turbo Pascal a Java , logica aziendale e amp; Le regole aziendali sono ciò che i vecchi e i nuovi progetti avrebbero in comune .

Il linguaggio di programmazione sarebbe diverso. Il codice sorgente sarebbe completamente diverso. Gli strumenti ( IDE s, compilatori e simili) potrebbero essere completamente diversi. L' interfaccia utente potrebbe essere interamente riorganizzata o avere un diverso look-and-feel . La documentazione sarebbe probabilmente diversa. Ma lo scopo dei due progetti, i risultati finali del lavoro svolto / obiettivi raggiunti, sarebbe lo stesso.

La logica aziendale consiste fondamentalmente in 2 ampie categorie: convalida e flusso. La logica aziendale afferma che qty 1 deve essere maggiore o uguale a qty 2 - ad esempio, il numero di articoli da acquistare deve essere inferiore o uguale al numero di articoli in magazzino.

In una applicazione, gli uomini d'affari diranno che questa è una regola aziendale e quindi si scrive codice per applicare questa logica aziendale (convalida). Un'altra applicazione dirà che se il numero di articoli ordinati è maggiore del numero di articoli in magazzino, per accettare l'ordine e quindi per inserire il proprio ordine per la differenza più il 20%, e così si scriverà questa logica di business (flusso) .

CRUD sta semplicemente recuperando e immagazzinando dati e conservandoli. La logica aziendale determina ciò che fai con quei dati e quali sono le trasformazioni che puoi fare. Il tuo cliente è nato in futuro, sotto i 5 anni, da una certa area geografica (sconti per locali / visitatori). CRUD è semplice, sapendo che è possibile ottenere un credito d'imposta per i figli solo se il bambino ha vissuto con te per più della metà del tempo in cui era vivo nell'anno solare NON più di 6 mesi, è più complesso.

La logica aziendale o le regole sono tutto ciò che non riguarda i meccanismi dell'interfaccia utente (le "cose di programmazione"). Sono le cose che dovresti ancora applicare se stavi facendo questa transazione o qualsiasi altra cosa 100 anni fa (manualmente). Ad esempio, quando applicare l'imposta sulle vendite a un acquisto.

La "logica di business" di un programma o di un'applicazione è la parte del codice che fa effettivamente cose con input (da parte dell'utente, del sistema operativo e così via). Le "regole aziendali" di un'applicazione sono in genere i parametri definiti del programma stesso (ad esempio come gestire l'input). Almeno, questo è il modo in cui ho sentito parlare di molte persone. Sono termini simili per descrivere parti del codice.