È 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.