Sarebbe OK se menzionassi l'attore nel comando / nome di query quando uso il modello CQS

Question

Sarebbe OK se menzionassi l'attore nel comando / nome di query quando uso il modello CQS

#1 da (0 voti)
#2 da (0 voti)

0

Sto applicando Clean Architecture + DDD (forse) nel mio progetto (web Application + REST API).

La cosa buona che ho imparato da Clean Architecture è l'utilizzo di "Interactors" per mostrare casi d'uso nel mio codice, che naturalmente si adattano al pattern Command. In modo che io usi i Command Patterns nel mio progetto.

Normalmente, ho chiamato il mio comando come "AddNewRequestCommand".

Ma sto pensando di cambiarlo in "AgentAddNewRequestCommand", che naturalmente si adatta alla mia user story e il comando stesso mostra il contesto completo del comando perché ogni caso d'uso ha bisogno di un attore.

Supponiamo di avere questa User Story:

In qualità di agente, desidero aggiungere una nuova richiesta di consegna, in modo da poter consegnare le mie merci.
Come agente voglio elencare la mia richiesta creata, in modo da poter gestire le mie richieste create.
In qualità di amministratore, desidero elencare tutte le richieste nel sistema, in modo da semplificare l'assistenza clienti

Risultato:

AgentAddNewRequestCommand
AgentListCreatedRequestQuery
AdministratorListAllCreatedRequestQuery

(Agente, Amministratore ... sono attori commerciali, non si tratta di ruoli / permessi)

Buono:

I comandi / Query mostreranno tutte le storie utente dell'applicazione
Comando / Query show actor & contesto del caso d'uso. In modo che possa ottenere un quadro più ampio del caso d'uso. Non devo fare una domanda del tipo: "Chi eseguirà questo comando"
Converti facilmente le storie degli utenti in Command / Query. In modo che, sviluppatore e amp; BA / PM può dire la stessa lingua.

Cattivo:

Provocherà un po 'di confusione tra attori e ruoli: che ne dici se sono un amministratore e un ampli; Voglio aggiungere una nuova richiesta.

Che ne pensi?

coding-style cqrs cqs

posta Hung Doan 27.07.2018 - 10:15

fonte

2 risposte

Leggi altre domande sui tag coding-style cqrs cqs

Tirando le metriche di analisi dall'applicazione java senza modifiche al codice Progettazione dell'app RecyclerView in Android

score 0 · Answer 1

0

Non consiglierei di farlo, in quanto complica i nomi delle classi di comando e può offuscare il loro intento.

Avere un campo UserId nei tuoi comandi è, comunque, una buona idea.

risposta data 27.07.2018 - 10:30

fonte

score 0 · Answer 2

Naming

Possiamo per favore smettere di nominare le cose male?

Solo perché qualcosa è un'implementazione di un pattern "Comando", non significa che devi aggiungere "Comando" ad esso. "AddNewRequest" è un comando. Si può dire perché è formulato come un imperativo, un comando in lingua inglese. Un comando " Comando " sta affermando in modo superfluo l'ovvio ed è forse un po 'condiscendente per i tuoi colleghi sviluppatori.

Allo stesso modo aggiungere "Agent" perché è usato da un agente non è di grande aiuto, e probabilmente è fuorviante. Perché, perché mai viene utilizzato "AddNewRequest", Sono comandi utenti . Se si tenta di stipulare l'utente, si verificheranno situazioni strane in cui si sta utilizzando un "Agente Comando " nei test, in un agente, nella console, da un altro comando, ecc ... Quindi è quel comando che usa "Agente Comando " sbagliato perché non è un agente?

Allo stesso modo, perché:

AgentListCreatedRequestQuery
AdministratorListAllCreatedRequestQuery

quando:

ListRequests
ListAllRequests

sono probabilmente migliori.

Se desideri mettere in discussione la "richiesta" di essere confusa con una "richiesta HTTP", quindi disegna dal tuo dominio:

ListDeliveryRequests
ListAllDeliveryRequests

Inoltre, a meno che non vi sia un motivo schiacciante per avere due funzioni di ricerca separate, è sufficiente abbatterle. Principalmente perché, come per l'esempio "Agente", non dovrebbero cercare di dettare chi è l'utente e sono identici a livello tecnico.

Sono un utente, desidero elencare le Richieste di consegna che si trovano in qualche stato, in modo da poter utilizzare tali informazioni.

Indipendentemente dal fatto che disponga di privilegi amministrativi o privilegi per un insieme di dati dei clienti, questo comando restituisce solo quelle Richieste che ho richiesto e che sono autorizzati a vedere.

ListDeliveryRequests

Associazione di storie utente al codice

Si prega di evitare le mappature uno a uno. Rende il codice fragile e il design scadente.

Queste storie non sono codice. Sono solo un modo per il cliente di provare ed esprimere ciò che vogliono che il software ti faccia. Passato che sono inutili. Il software diventa la definizione.

Per il contesto, immagina che domani il cliente affermi che sia gli agenti che l'amministratore devono essere in grado di ottenere le richieste ordinate per data.

Se hai implementato una mappatura uno a uno, stai facendo il doppio del lavoro, hai il doppio codice, raddoppi i bug e quando correggi un bug per un gruppo e dimentichi di aggiornarlo altrove raddoppia la perdita di reputazione.

Se hai implementato la funzionalità in modo più efficiente comprendendo l'intento sottostante, puoi ridurre il carico di lavoro, ridurre la quantità di codice, ridurre il numero di bug e sapere che quando il bug è corretto, non ti perseguita altrove .

Autorizzazione

Passare le informazioni dell'utente nei tuoi comandi è logico, altrimenti come sarà correlata correttamente la nuova Richiesta con l'utente e in che modo la ricerca recupera solo le richieste che l'utente può vedere?