This is a design question where I am trying to accommodate a business need.
I have two entities – Item
and Job
.
Original Situation
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.
Example:
1. Item "Toaster"
2. Item "Warranty on Toaster"
3. Item "Discount"
Normally a 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 ordered
, reviewed
, manufactured
, shipped
and is visible on an item tracker to all in manufacturing and shipping.
The Change
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.
Question
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).
Thought 1
If each 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.
Thought 2
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?
Best Answer
The canonical solution for these different processes for different items is to have a separate class for each kind of process.
Your existing
Job
would become an abstract class or interface, and you would get a hierarchy of Jobs like thisThe
ManufacturingJob
class represents the workflow for items that need to be manufactured (comparable to the existingJob
). ThePrintingJob
class represents the workflow for items that only require some paperwork to be printed, like the warranty papers or the manuals. TheMiscellaneousJob
class is for those items that either don't require explicit processing or where the processing flow is so special that it can't be captured in your system.In the manufacturing department, only the
ManufacturingJob
s would be visible and their associated items, while thePrintingJob
s and associated items would only be visible to the department(s) dealing with printed materials.