如何设计一个项目跟踪系统，在整个产品生命周期中跟踪不同类型的项目？

Question

这是一个设计问题，在这里，我试图满足业务需求。

我有两个实体-- Item和Job。

原始情境

Item表示分类帐上的一个行项目，而Job只为那些需要它的Item对象创建(即，在从一个部门到另一个部门--订单、采购、制造、准备发货、发货等)中跟踪通过状态更改过程的行项目的Job。我有Job::status字段来跟踪状态更改。

示例：

1. Item "Toaster"
2. Item "Warranty on Toaster"
3. Item "Discount"

通常，创建的Job只适用于第一项，因为这是唯一需要通过生产周期的项目。在这个周期里，它对所有参与制造它的人都是可见的。所有其他项目都是由内存和系统外处理的，即做笔记和记忆处理它们。

项目1的Job::status经历了诸如ordered、reviewed、manufactured、shipped等状态变化，并且在项目跟踪器上对所有制造和运输人员都是可见的。

The Change

现在有业务需要跟踪所有的项目，以便它们都可以被“处理”。也就是说，即使#2不需要制造，仍然需要有人准备保修文件，并确保他们被运送。

这就产生了一个问题，因为使用现有的代码，为第2和第3项创造就业机会，就会使它们进入生产周期。在车间组装零件的机械师会看到这些物品，当它们与保证或折扣无关的时候。如果不创建这些工作机会，其他需要在这些项目(2，3)上工作的人将不会在项目跟踪器中看到它们。

问题

下面是我的问题--如何设计对现有的代码基础结构进行更改，使之能够通过不同的周期来处理跟踪项的机制。这可能意味着重用现有的周期，或者创建新的循环并将它们粘合在一起，或者其他的东西。

我很可能最终会修改现有的方法和/或在其之上构建，以满足业务需求。

我到目前为止所做的一切

我已经做了一个改变，每个Item都得到了一份工作，即使它的状态机会周期与前面提到的不同。这有助于非制造人员查看和跟踪内部作业路由系统中的项目，即使“折扣”通过‘制造’、‘订购’和‘发运’阶段。而且，所有的制造业人士都会看到折扣项目，并且不得不把工作推到下一个周期，这样就可以进行处理，即使他们与之无关(他们制造烤面包机，而不是折扣)。

认为1

如果每个Item都有一个Job，那么我最好将它们合并在一起，并扩展它们的状态以适应不同类型的项。这可能很复杂，我不喜欢这个解决方案。

思想2

或者，我可以将status属性从Job移动到Item中，然后创建不同跟踪Item的不同实体。即传统作业周期(如项目1 )的Job，以及项目2和3等不同类别的Item的JobSomethingElse。这可能不是很理想，因为这涉及对现有基础结构的广泛更改(目前所有状态都属于Job实体)，将它们转换为Item需要相当大的努力+调试。

总的来说，我不太清楚如何设计或如何设计，以便在业务的整个生命周期中正确地跟踪每个itme。这里有什么图案或设计可以帮我吗？

Answer 1

对于不同项的这些不同过程的规范解决方案是，对于每种过程都有一个单独的类。

您现有的Job将成为一个抽象类或接口，您将得到这样的作业层次结构

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

ManufacturingJob类表示需要制造的产品的工作流(可与现有的Job相比较)。PrintingJob类表示只需要打印一些文件的项目的工作流，如保修文件或手册。MiscellaneousJob类用于那些不需要显式处理或处理流非常特殊以至于无法在系统中捕获的项。

在制造部门，只有ManufacturingJobs和他们的相关项目是可见的，而PrintingJobs和相关的项目只有在处理印刷材料的部门(包括)中才能看到。