1

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?

Improve this question
2
  • It isnt really clear to me what you can and can't do. Can you just add a "department" field to your job object, then filter jobs in the view based on that field? IE a warranty item comes in and the warranty dept sets the job to repair, then the repair dept sees the item, does the job, sets the job to ship, shipping then sees it.... Commented Apr 25, 2017 at 20:50
  • I would use something other than 'department', just in case, let's say currentStatus field, to indicate current step of the process. For Toaster we have {received for manufacturing, manufactured, assembled, ready to ship, shipped}. For Warranty I meant that item to be something like a paper booklet to go with the toaster and not something that is to be repaired, but something that can be printed and compiled into the booklet form. It can be a different cycle, such as {received for processing, printed, ready to ship, shipped}. How would you track these different cycles? Commented Apr 25, 2017 at 21:29

1 Answer 1

Reset to default
2

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 this

interface Job { ... } class ManufacturingJob : implements Job { ... } class PrintingJob : implements Job { ... } class MiscellaneousJob : implements Job { ... }

The ManufacturingJob class represents the workflow for items that need to be manufactured (comparable to the existing Job). The PrintingJob class represents the workflow for items that only require some paperwork to be printed, like the warranty papers or the manuals. The MiscellaneousJob 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 ManufacturingJobs would be visible and their associated items, while the PrintingJobs and associated items would only be visible to the department(s) dealing with printed materials.

Improve this answer
3
  • thank you I have been leaning this way myself, and having confirmation helps Commented Apr 26, 2017 at 13:34
  • @Dennis you may also want to look into the Chain of Command pattern to supplement this. Commented Apr 26, 2017 at 13:55
  • What will be the chain in this case? I think in my case I can define exactly what job type gets assigned to what item by using item's part number. I can do direct routing this way and I don't see a need to chain them ... Commented Apr 26, 2017 at 13:59

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.