Questa è una domanda di progettazione in cui sto cercando di soddisfare le esigenze aziendali.
Ho due entità: Item e Job .
Situazione originale
Item rappresenta un elemento pubblicitario su un libro mastro e Job viene creato solo per quegli oggetti Item che ne hanno bisogno (cioè un Job per tracciare l'elemento pubblicitario che attraversa il processo di modifica dello stato mentre andava da un reparto all'altro - ordine, acquisto, produzione, pronto per la spedizione, spedizione, ecc.). Ho il campo Job::status per tracciare i cambiamenti di stato.
Esempio:
1. Item "Toaster"
2. Item "Warranty on Toaster"
3. Item "Discount"
Normalmente viene creato un Job per l'articolo 1 solo perché è l'unico che deve passare attraverso il ciclo di produzione. In quel ciclo diventa visibile a tutte le persone che sono coinvolte nel produrlo. Tutti gli altri elementi sono stati gestiti dalla memoria e dall'out-of-the-system, ovvero creando note e remebering per elaborarle.
Job::status per l'articolo 1 passa a tali cambiamenti di stato come ordered , reviewed , manufactured , shipped ed è visibile su un tracker di articoli a tutti in produzione e spedizione.
Modifica
Ora c'è bisogno di tenere traccia di tutti gli articoli, in modo che tutti possano essere "elaborati". cioè, anche se il # 2 non ha bisogno di essere fabbricato, qualcuno ha ancora bisogno di preparare i documenti di garanzia e assicurarsi che vengano spediti.
Questo crea un problema, poiché con il codice esistente, creando lavori per gli articoli 2 e 3, li inserisce nel ciclo di produzione. E i macchinisti che mettono insieme le parti in officina vedranno quegli articoli, quando non hanno nulla a che fare con la garanzia o lo sconto. Senza creare quei lavori, qualcun altro che ha bisogno di lavorare su quegli elementi (2, 3), non li vedrà nell'elemento tracker.
Domanda
Ed ecco la mia domanda: come progettare di apportare una modifica all'infrastruttura di codice esistente dove c'è un meccanismo che si occupa di tracciare gli articoli attraverso cicli diversi. Questo può voler dire riutilizzare cicli esistenti, o crearne di nuovi e incollarli insieme, o forse qualcos'altro.
Molto probabilmente finirò per modificare l'approccio esistente e / o per crearlo sopra, per soddisfare le esigenze aziendali.
Cosa ho fatto fino ad ora
Ho apportato una modifica in cui ogni singolo Item ottiene un lavoro, anche se il suo ciclo di probabilità di stato è diverso da quello menzionato prima. Questo aiuta le persone non di produzione a vedere e tracciare gli articoli nel sistema di routing di lavoro interno, anche se "Sconto" passa attraverso la fase di "produzione" e "ordinamento" e "spedizione". Inoltre, tutte le persone manifatturiere vedono l'oggetto sconto e devono spingere il lavoro fino al ciclo successivo in modo che possa essere elaborato, anche se non hanno nulla a che fare con esso (producono tostapane ma non sconti).
Pensiero 1
Se ogni Item ottiene comunque una Job , potrei anche unirle e estendere i loro stati per adattarsi a diversi tipi di elementi. Questo può essere contorto, e non mi piace questa soluzione.
Pensiero 2
In alternativa, posso spostare la proprietà di stato da Job a Item , quindi creare entità diverse che tracciano Item in modo diverso. vale a dire Job per il ciclo di lavoro tradizionale, come l'elemento 1 e JobSomethingElse per una diversa classe di Item come gli articoli 2 e 3. Ciò potrebbe non essere molto auspicabile in quanto comporta modifiche estese dell'infrastruttura esistente (tutti gli stati appartiene all'entità Job al momento) e il loro spostamento in Item è uno sforzo considerevole + debugging.
Nel complesso non sono molto chiaro su come progettare o cosa progettare per tracciare correttamente ogni itme attraverso il suo ciclo di vita nel business. Ci sono schemi o disegni che possono aiutarmi qui?