Incapsula una storia aziendale / caso d'uso in una classe?

Question

Incapsula una storia aziendale / caso d'uso in una classe?

#1 da (2 voti)

2

Non mi piacciono le classi come *Service , con molti metodi di business, ovvero un modello anemico. Stavo pensando, invece, ad avere una classe per caso d'uso. Questo è stato ispirato (se non lo stesso) da CQRS. Anche se non stiamo usando l'event sourcing, credo che questo tipo di incapsulamento avrebbe senso. Quindi il livello di servizio (livello applicazione) sarebbe costituito da semplici comandi che l'utente può creare e trasferire ad alcuni utenti.

Questo avrebbe senso?

Ecco alcuni requisiti (esempio):

utente crea un sondaggio con una domanda e almeno 2 scelte
aggiornamenti degli utenti sondaggio e scelte; le scelte possono essere solo aggiunte
l'utente può votare per una scelta, l'aggiornamento della domanda deve essere aggiornato

ecc.

Questi sono scenari di business / casi d'uso, comunque li vuoi chiamare. Contengono la logica di business (come abbiamo bisogno di almeno 2 scelte, ecc.). Stavo pensando in:

public class CreatePollCommand implements Command {

    @Inject
    Repository_Validator_whatever_infrastructure_we_need

    public CreatePollCommand(input_arguments) {
    }

    public void execute() {
        // write business logic here
    }
}

E può essere usato dal livello di presentazione:

executor.run(new CreatePollCommand(input_from_ui));

Quindi l'esecutore inietta tutto ciò che deve iniettare e questo è tutto.

architecture cqrs

posta lawpert 18.11.2014 - 21:05

fonte

1 risposta

Leggi altre domande sui tag architecture cqrs

Utilizzo dei comandi DDL nel linguaggio di programmazione [duplicato] Mantieni la tua libreria di utilità [duplicata]

score 2 · Accepted Answer

La presenza di un livello di servizio non implica necessariamente che il modello sia anemico. Un livello di servizio potrebbe fornire una facciata semplificata a un modello di dominio complesso. Cioè un utente aziendale può semplicemente voler creare un nuovo sondaggio. L'interfaccia utente è semplificata se parla in questi termini e il livello di servizio tradurrà da ciò che l'interfaccia utente comprende in operazioni che sfruttano il modello di dominio.

Che si tratti di un esecutore che interpreta comandi o chiama un livello di servizio, alla fine qualcuno eseguirà operazioni contro il modello di dominio.

Ora se il livello esecutore / servizio è responsabile di eseguire tutto il CRUD sugli oggetti per eseguire la transazione, allora hai un modello anemico.

Facciamo un esempio.

Il tuo modello sul back-end avrà un sondaggio con domande che contengono risposte ci sarà un proprietario per il sondaggio (molto probabilmente la persona che lo crea) insieme a una serie di altri oggetti creati (fatturazione, auditing, ecc.) che l'utente potrebbe non vedere. Il Sondaggio potrebbe avere un determinato numero di Rispondenti consentiti (identificati da un elenco di email) e potrebbe essere necessario generare Invito per i rispondenti (email)

Ora immagina se il tuo esecutore fosse responsabile della generazione di tutti quegli oggetti direttamente e di collegarli insieme ... sarebbe un modello anemico. Un modello robusto utilizza la radice Aggregate per gestire tutte le operazioni richieste.

Ad esempio, l'Executor potrebbe ottenere l'account in cui verrà creato il sondaggio e chiamare

var poll =Account.CreatePoll(cmd.PollName, cmd.CampaignId /*you get the point*/);

L'oggetto Account è responsabile della creazione del sondaggio e del suo vincolo all'account, alla campagna e ad altri dettagli che comprende su come funzionano i suoi sondaggi. Aggiungerebbe anche il sondaggio alla sua raccolta Sondaggi.

Successivamente l'esecutore eseguirà il resto delle sue operazioni sul Poll restituito dalla chiamata precedente.

foreach (var question in cmd.Questions)
{
  poll.AddQuestion(question.Prompt, question.Answers);
}

//cmd.Respondents is a comma separated list of strings containing respondent emails
//or a list of emails
poll.AddRespondents(cmd.Respondents);
unitOfWork.Commit();

Come vedi il robusto modello prende oggetti semplici e costruisce gli oggetti di dominio appropriati secondo la logica interna. Con un modello anemico, l'esecutore o il livello di servizio sarebbe responsabile dell'istanziazione di ogni domanda e dell'aggiunta a una proprietà Poll.Questions. E facendo lo stesso con le risposte. Potrebbero esserci anche oggetti intermedi tra le domande e il sondaggio che il sondaggio sarebbe responsabile della costruzione perché possiede il suo aggregato.

In ogni modo lo si affetta, il livello del comando o del servizio è progettato per semplificare la complessità del dominio per i suoi clienti.