This is a design question where I am trying to accommodate a business need.
I have two entities -
Item represents a line item on a ledger, and
Job is created only for those
Item objects that need it (i.e. a
Job to track the line item going through the status change process as it went from one department to another - order, purchase, manufacture, ready to ship, shipped, etc). I have
Job::status field to track the status changes.
1. Item "Toaster" 2. Item "Warranty on Toaster" 3. Item "Discount"
Job created would for item #1 only as that's the only one that needs to go through the manufacturing cycle. In that cycle it becomes visible to all the persons that are involved in manufacturing it. All other items were dealt with by memory and out-of-the-system, i.e. making notes and remebering to process them.
Job::status for item 1 goes through such status changes as
shipped and is visible on an item tracker to all in manufacturing and shipping.
Now there is business need to track all the items, so that all of them can be "Processed". i.e. even though #2 does not need to be manufactured, someone still needs to prepare the warranty papers and make sure they get shipped.
This creates a problem, since with existing code, creating jobs for items #2 and #3, puts them into the manufacturing cycle. And machinists putting parts together on the shop floor will see those items, when they have nothing to do with Warranty or Discount. Without creating those jobs, someone else who needs to do work on those items (2, 3), will not see them in the item tracker.
And here is my question - how do I design making a change to the existing code infrastructure to where there is a mechanism that takes care of tracking items through different cycles. This may mean reusing existing cycles, or creating new ones and gluing them together, or maybe something else.
Most likely I will end up modifying existing approach and/or building on top of it, to meet the business need.
What I have done so far
I've made a change where every single
Item gets a job, even if its status chance cycle is different then one mentioned before. This helps non-manufacturing folks see and track the items in the internal job routing system, even if "Discount" goes through the 'manufacturing' and 'ordering' and 'shipped' phase. Also, all manufacturing folks see the Discount Item and have to push the job through on to the next cycle so it can be processed, even if they have nothing to do with it (they make toasters but not discounts).
Item gets a
Job anyway, I might as well merge them together and extend their statuses to accommodate for different types of items. This may be convoluted, and I don't like this solution.
Alternatively I can move the status property from the
Job into the
Item, and then create different entities that track
Item differently. i.e.
Job for traditional Job cycle, such as item 1, and
JobSomethingElse for a different class of
Item such as items 2 and 3. This may not be very desirable as this involves extensive changes to existing infrastructure (all statuses belong to the
Job entity at the moment), and shifting them into
Item is considerable effort + debugging.
Overall I am not very clear on how to design or what to design to track each itme properly through its lifecycle in the business. Are there any patterns or designs that can help me here?