gerarchia Specializzazione in un modello di dominio

Question

Sto cercando di rendere il modello di dominio di un sistema di gestione. Ho la seguente tipo di persone in questo sistema:

employee
manager
top mananger

Ho deciso di definire un User, da dove Employee, Manager e Top Manager si specializzerà da. Ora, io non so che tipo di gerarchia specializzazione dovrei scegliere. Non riesco a decidere tra le seguenti modi:

o

Il che potrebbe essere preferibile e perché?

Come un lungo codificatore tempo, ogni volta che cerco di fare un modello di dominio, devo lottare contro l'idea di cercare di pensare in modo ho intenzione di codice di questo. Da quello che ho capito, non dovrei pensare a quelle cose nel-modello di dominio, solo in relazioni oggettuali. Non devo pensare a duplicazione di codice o di uno qualsiasi di questi tipi di dettagli qui, quindi non posso davvero scegliere una delle opzioni sopra l'altro.

Grazie

Modifica

sarò un po 'più esplicito: Questo è un programma per gestire i piani di vacanze del lavoratore. Con questo programma, un dipendente può scegliere il set di Vacanze giorni per l'anno. Poi il manager potrebbe approvare o no quei giorni per ognuno dei dipendenti e alla fine della giornata il top manager dovrebbe approvare o disapprovare le decisioni del gestore. Si tratta di tutti gli utenti del mio programma si suppone siano in grado di fare. Non ci sono altre attività.

Answer 1

Questo viene per lo più verso il basso per una questione di come si definiscono i termini. La questione fondamentale è se un manager può essere sostituito per un dipendente in ogni possibile circostanza - e senza conoscere il precisa le regole del mondo del lavoro in corso di modellazione, è impossibile dire in un modo o l'altro a tale proposito.

Una nozione generale è che sì, almeno fino a un certo punto, in un pizzico un manager dovrebbe essere in grado di fare il lavoro di uno dei suoi subordinati (almeno un livello al di sotto, e molto probabilmente due o tre).

D'altra parte, in alcuni punti con un sacco di regole sindacali-driven in atto, che potrebbero non essere il caso a tutti. Anche se una persona è del tutto in grado di fare un lavoro, le regole possono impedirgli di sostituire in quella posizione a tutti. In alcuni casi questo nasce da requisiti di certificazione e simili (ad esempio, il gestore può avere uno stato qualificato per fare il lavoro, ma la certificazione richiesta è scaduta) o da cose come regole sindacali (ad esempio, un mio amico che una volta fu rimproverato perché portava una lampadina torcia elettrica e la batteria dalla società negozio di nuovo al suo laboratorio invece di ottenere un sindacato materiali gestore di farlo per lui).

Answer 2

Nella vita reale, i manager sono dipendenti troppo. Quindi questo è sicuramente solo una catena di crescente specializzazione:

User -> Employee -> Manager -> Top Manager 

modifica

  

"Questo è un programma per gestire il   vacanze piani dei lavoratori ".

I gestori In compagnia fanno prendere in programma vacanza? Sicuramente lo fanno. E altrettanto sicuramente non si ha intenzione di costruire un'applicazione separata per gestire tale. Quindi, ciò che ha realmente bisogno è questa:

User -> Requester
     -> Approver

Ogni utente sarà un richiedente in una catena di approvazione. (Potrebbe essere necessario un regime speciale per l'amministratore delegato). Inoltre alcuni utenti saranno approvazioni in una o più catene. Il responsabile approvazione finale sarà probabilmente variano a seconda del grado del richiedente: il CEO non vorrà preoccuparsi se stessi con le modalità di approvazione di vacanza del personale pulizie

.

Sarà necessario rispettare alcune regole per chi può essere un responsabile approvazione di un determinato vacanze del richiedente. A meno che non si dispone di un'organizzazione estremamente piatta troverete di avere una gerarchia di lavoratori e dirigenti. Per esempio, un Team Leader o di un caposquadra - individui che si trovano in altri aspetti "lavoratori", piuttosto che "manager" - possono essere nella catena. Inoltre potrebbe essere necessario prendere in considerazione altri aspetti dell'organizzazione. P. esempio, se il lavoratore intenda svolgere lasciare verso il prossimo anno che potrebbe richiedere l'approvazione del reparto risorse umane, qualcuno che normalmente ha alcuna responsabilità gestionale per il dipendente di sorta.

Modifica 2

Ok, quindi stiamo modellando un insieme arbitrario di regole piuttosto che uno scenario realistico.

vedi Let. Ogni utente si inserisce in una singola categoria, definiti da queste attività:

• un dipendente può domandare
• un manager può approvazione o rifiuto di una richiesta Abbandona
• un Top Manager può accettare o sovvertire un approvazione o il rifiuto

dirigenti e vertici non hanno comportamenti in comune. Di conseguenza, il primo modello è quello corretto.

Answer 3

Vorrei modellare questi come attori. Essi non sono il dominio del sistema, ma gli utenti del sistema. Ti modellare sistema di inventario di un negozio con 'scuola-ragazzo che vuole i dolci', 'genitore della scuola-ragazzo che vuole tabacco', 'impiegato', ecc? Anche se solo uno store manager (attore) può dare rimborsi senza una ricevuta, ciò che conta a livello di sistema è che il sistema riconosce la chiave del responsabile del negozio, ed è che il permesso di token che è nel software, piuttosto che ruolo l'attore prende.

Il dominio del sistema che si descrive è le richieste di ferie e l'account utente, e alcuni dei casi d'uso significa che alcuni dei conti hanno il permesso di eseguire determinate trasformazioni di stato a una richiesta di vacanza.

La differenza nella modellazione Utente / Gestore / Impiegato come attori e ruoli è che è possibile concentrarsi sulla modellazione ciò che è necessario mettere in sistema, in quanto non è necessario avere gerarchie di attori - di cominciare ad usare l'astrazione in uso cassa e entità sistema livelli, piuttosto che negli attori. Non è sempre una cattiva idea pensare 'come sarebbe questo lavoro nel codice', almeno per quanto riguarda come chiedere 'perché preoccuparsi di codifica questa distinzione'.