La logica di presentazione vincola la progettazione del livello aziendale?

4

Abbiamo un plug-in e-mail che crittografa gli allegati di una posta quando l'utente invia una e-mail e concede ai destinatari della posta le autorizzazioni per decrittografare gli allegati. Le autorizzazioni del destinatario sono memorizzate su un server. La logica che viene eseguita al clic del pulsante Invia comporta anche alcune richieste dell'utente. Ad esempio, se alcuni dei destinatari sono nuovi, al mittente viene prima richiesto di confermare che i nuovi destinatari verranno creati sul server.

Progettando questo sistema, ho sentito che la logica della presentazione vincolava la mia progettazione del livello aziendale. Poiché ci sono richieste da mostrare al mittente a determinati intervalli nell'elaborazione dell'evento Invia, i miei servizi aziendali devono essere suddivisi in RecipientService e MailEncryptionService , uno per registrare nuovi destinatari e altro per crittografare gli allegati, ciascuno chiamato da Livello di presentazione. Se, tuttavia, non ci fosse l'esigenza di richiedere all'utente intermedio, avremmo potuto creare un terzo componente aziendale MailService che ha fuso RecipientService e MailEncryptionService e gestito l'intera logica di business di Send in una singola operazione ProcessSend che potrebbe essere stato chiamato dal livello Presentazione. Ritengo che si tratti di business logic poiché è la stessa logica che viene eseguita in tutte le piattaforme supportate. Inoltre, se questo processo avvenisse in modalità back-end completamente silenziosa, forse sarebbe stato conveniente avere una singola chiamata per questo.

È giusto pensare? La logica di presentazione mette un vincolo sulla progettazione del livello aziendale? O sbaglio nel fondere i 2 servizi distinti in un unico MailService ? Se è così, perché? Come decidere quali servizi aziendali distinti possono essere uniti in quelli più alti?

    
posta Kapil Dhaimade 02.03.2018 - 09:30
fonte

3 risposte

5

È una buona domanda. A volte le complessità del mondo reale rendono più difficile vedere il quadro generale e / o sono in conflitto con i nostri modelli mentali. Dovrò fare una digressione un po 'prima di arrivare alla tua vera domanda, ma avere pazienza con me.

L'idea chiave è che il nucleo centrale della tua applicazione è il modello (software) del problema aziendale che stai cercando di risolvere. Un modello software è semplicemente una rappresentazione software del vero problema o processo, cioè un modo di guardare le cose, un modo di pensare al dominio e porta con sé determinati concetti, relazioni e varie altre idee. Sottolinea le cose che sono ritenute importanti dagli sviluppatori e ignora i dettagli ritenuti insignificanti. Nota che ciò significa che possono esserci più di una rappresentazione. Puoi modellare un dominio in più di un modo, e diversi modi avranno pro e contro diversi. Alcuni modelli saranno più flessibili di altri, a seconda del tipo di applicazioni che stai realizzando. In generale, non progetterai la migliore rappresentazione al primo tentativo (qualunque cosa "migliore" risulti alla fine).

Ora, quando parliamo dell'accoppiamento e della direzione delle dipendenze tra i vari componenti del software, stiamo parlando dei dettagli tecnici della struttura del nostro sistema. Vogliamo assicurarci che le modifiche si propagino solo in determinate direzioni. Tuttavia, le vere forze che guidano il cambiamento nel software sono le persone - il business & gli utenti (hanno bisogno del software per fare certe cose in un certo modo) e gli sviluppatori (dobbiamo rendere il nostro software mantenibile, ecc.)

Quindi, se l'azienda ha bisogno dell'applicazione per mostrare determinati prompt tra le parti del flusso di un processo aziendale, si tratta di una forza esterna che influisce, a un livello, sulla logica dell'applicazione (specifica), ma su un'altra, riflette come pensano al processo aziendale stesso. Nella loro mente, ha passaggi ben definiti (almeno in alcune circostanze o in alcune condizioni). Devi incorporarlo nel tuo modello di dominio , in modo che rappresenti meglio il loro processo di business effettivo. Se ci pensi in questo modo, sono proprio le esigenze aziendali a influenzare sia la logica aziendale che, a sua volta, la logica dell'applicazione. Dal lato tecnico, si mantiene la logica dell'applicazione dipendente dalla logica di business in fase di compilazione (la direzione delle dipendenze è verso la logica aziendale), in modo che la modifica dei dettagli di come si implementa il livello logico dell'applicazione non influisce sul livello aziendale . Ma ogni volta che la stessa logica aziendale cambia, probabilmente interesserà altre parti del sistema (motivo per cui è considerato il nucleo dell'applicazione).

Infine, se si presenta la necessità di qualcosa come un servizio che esegue questi passaggi come operazione singola, significa che l'azienda pensa al proprio processo di business in due modi diversi. Ad esempio, ci sono due realizzazioni dello stesso concetto generale. Se si desidera riutilizzare lo stesso modello di dominio per entrambi i casi, il modello di dominio deve essere in grado di supportare (rappresentare) entrambi questi elementi e, se i passaggi sono modellati come componenti software indipendenti ma componibili, è possibile farlo facilmente. Se ciò non è facilmente realizzabile, potrebbe essere necessario riprogettare il modello di dominio in una certa misura, per assicurarsi che supporti entrambe le applicazioni. Quindi, con l'aumentare del numero di applicazioni specifiche con richieste specifiche, aumenta la generalità del modello di dominio riutilizzato. Tranne a volte risulterà impossibile, scomodo o poco pratico avere un modello di dominio condiviso, e potresti decidere che è meglio avere due modelli separati: la tua vista concettuale cambia. Quindi, la tua rappresentazione si evolve nel tempo (e su diverse applicazioni) e il tuo compito è davvero quello di controllare il modo in cui tale processo si riflette sulla base di codice.

In sintesi, non è la presentazione che limita la tua logica di business, ma sono le esigenze del business che guidano tutto.

    
risposta data 02.03.2018 - 11:27
fonte
2

Non dovresti permettere alla logica di presentazione di guidare la logica del business.

Ma nel tuo caso non sono sicuro che lo sei.

È necessario verificare l'esistenza dei destinatari prima dell'invio. Questo è un requisito aziendale.

Mail.Send() should fail if the recipients don't exist already

Quindi hai un requisito di presentazione intorno alla creazione di nuovi destinatari, che venga mostrato un popup. Ma sta facendo lo stesso controllo che già fa Mail.Send. Verifica dell'esistenza di un destinatario.

Potresti automatizzare la creazione del destinatario se non ci fosse questo requisito di presentazione, ma forse c'è una regola aziendale sottostante. Forse un requisito legale!

A user must positively affirm the creation of new recipients

Potrebbe trattarsi di un popup o di una casella di controllo o di una procedura guidata, questo è il bit di presentazione, ma la regola aziendale esiste al di sotto.

    
risposta data 02.03.2018 - 12:42
fonte
1

In definitiva, un'applicazione dovrebbe soddisfare le esigenze specifiche dei suoi utenti, entro un ambito richiesto, dati i vincoli del dominio. (Ci sono informazioni rilevanti su "Behaviour Driven Development" (BDD) o "use case".) Nel tuo esempio sono probabilmente i requisiti dell'utente che "vincolano" sia il livello aziendale che il livello di presentazione. Ad esempio, una "user story" supportata dall'app potrebbe essere:

Come mittente dell'e-mail
Voglio essere informato sui nuovi destinatari della mia email
In modo che io (ad esempio, ho ottenuto i nomi corretti OR potrebbe salvarli o non ricevere spam, ecc.)

Naturalmente, c'è anche il rischio che il livello aziendale dipenda dal livello di presentazione: è difficile dirlo senza ulteriori dettagli sull'esempio.

    
risposta data 02.03.2018 - 10:45
fonte

Leggi altre domande sui tag