Aggancia il metodo di accesso ai dati su un oggetto sbagliato dannoso per uno sviluppatore

Doing them on adminStore will make them sensible in sense developer would understand that admin is creating the user and has access role.

La politica aziendale ha poco a che fare con queste decisioni di progettazione. Le politiche cambiano frequentemente. Basta evitare di creare dipendenze circolari e funzionerà. Ad esempio, se createUser chiama i metodi in AdminStore e AdminStore dipende già da UserStore , quindi inserisci il metodo in AdminStore . Se createUser non ha dipendenza su AdminStore , o se UserStore dipende già da AdminStore , quindi inserisci il metodo in UserStore .

Ho scoperto che scrivere il test del codice mi porta prima a un progetto praticabile quasi automaticamente. Se avessi scritto un test unitario per createUser e non avessi bisogno di istanziare AdminStore per definire il test, sarebbe un strong segnale che il createUser appartiene in UserStore e non in AdminStore .

Non soffermarti troppo a lungo su queste piccole decisioni di design. Scegline uno e torna al lavoro. Più tardi potresti vedere che sarebbe meglio il contrario. Nessun problema. È solo codice. Cambialo.

Quando vedi un'applicazione o una libreria ben progettata, è quasi certamente il risultato di un sacco di refactoring, e non il risultato di un brillante design iniziale.

Non sono sicuro del tuo modello di oggetti, ma vorrei creare una classe utente e altre 2 classi che ereditano dall'utente. Una classe sarebbe la classe admin e l'altra è la normale classe utente. Un metodo come CreateUser sarebbe la responsabilità della classe admin che eredita dalla classe utente. Facoltativamente, puoi scegliere di rendere la classe super user una classe astratta.

Una nota a margine: qui devi considerare cosa succede se un amministratore diventa un utente normale e cosa succede se un utente normale diventa un amministratore? Il tuo modello dovrebbe adattarsi a questo.