我一直在开发一个基本上是 CRUD 应用程序（创建、读取、更新、删除）的 Web 应用程序。最近，我开始研究我所说的“审批工作流程”。基本上，会为材料生成请求，然后将其发送给经理以供批准。根据请求的内容，不同的人需要批准请求，或者可能将其发送回请求者进行修改。批准者需要跟踪批准哪些内容已批准，请求者需要查看其请求的状态。
作为“CRUD”开发人员，我很难思考如何设计它。我应该有哪些数据库表？如何跟踪请求的状态？我应该如何通知用户他们的请求发生的操作？
他们的设计模式可以帮助我吗？我应该在我的代码中绘制状态机吗？
我认为这是一个通用的编程问题，但如果它有任何区别，我将使用 Django 和 MySQL。
为此有设计模式。也许他们会有所帮助：
http://en.wikipedia.org/wiki/Workflow_patterns
工作流比简单的 CRUD 应用程序更受状态驱动，所以是的，阅读状态机模式也会有所帮助。听起来你在正确的轨道上。
至于数据建模，您可以拥有一个包含所有“批准”的表，其中的状态字段是状态表的外键。
至于通知，这是您的应用程序在更改批准状态时必须做的事情，它必须在其他地方查找特定状态更改需要通知谁/什么（因此您必须跟踪什么实体会收到有关哪些状态更改的通知）。
批准 == 状态变化
状态更改 == 更新更改的内容 && 创建日志以记录更改的内容。
而已。
有趣的规则是“谁可以进行更新？”、“哪些状态更改是合法更新？”和“哪些状态是死胡同？”
你正在构建一个有限自动机。状态是对象的属性。您通过更新其状态来“通过工作流程”推动某些东西。
正如许多人所说，批准它就是把它带入一个新的状态。
我遇到的需要考虑的事情是，我经常发现用户希望让事物处于相同的“状态”，但也记录事物在该状态下处于不同的步骤或任务中。例如，用户可能想要区分“请求”和“处理中”。从批准的角度来看，请求的和处理中的都是未批准的（打开的）。如果某件事从批准变为未批准（开放），他们可能会称其为“需要审查”——但它仍未获得批准。
所以你可能想要这样的东西：
要求：打开
处理中：打开
需要审查：打开
已批准：已批准
随着时间的推移，您的用户可能会想要更多的“模式”或“任务”。如果您为其中的每一个都创建一个状态，您最终可能会比您或他们真正想要的复杂得多。如果您让用户拥有尽可能多的“模式”或“任务”，并且与状态具有多对一的关系，那么从您的角度来看会更简单，但从用户的角度来看会更精确。
我们经常遇到这种情况，以至于我们制作了一个通用的路由系统。对于您正在做的事情来说，这可能是矫枉过正，但欢迎您挖掘它的想法。它允许使用链（顺序批准）或星号（广播）将任意内容路由到任意用户，并通过最少的投票来批准。这是模式的自动生成的 ERD。
基本上，我们有一个包含一个或多个路由方案列表的路由方案。每个列表可以是链式或星形，整个方案可以以链式或星形启动。每个列表和整个方案都可以有自己的 votes_to_approve。这意味着您可以有一个带有两个列表、一个星形和一个链的“星形”类型的方案。整个方案的 votes_to_approve 可以为 1，因此如果任一列表获得批准，则整个工作流程都会获得批准。链表的 votes_to_approve 可以等于成员的数量，这样每个成员都必须在下一个成员投票之前批准，并且第一个不批准的成员会杀死该列表。在星级列表中，您可以将 votes_to_approve 设为 1，以便该列表中的任何人都可以立即批准整个工作流程
这些方案被无限期保存，一旦设置就可以重复使用。为了实现一个方案，在路由表中创建一个条目，其中包含 scheme_id、要路由的事物以及一些细节，如批准和不批准文本。然后，“routing_”表存储已实施方案的状态。
我们使用跨应用程序事件系统来发送电子邮件，或在路由更改状态时通知其他应用程序。
我现在在一个类似的项目中（不同的平台/数据库）。
我有一个数据库应用程序，它具有不同级别的用户权限，以了解他们可以对哪些类型的记录进行 CRUD。在大多数情况下，我控制代码中允许的操作。
但是，对于许多构造，我有构造的“状态代码”，然后定义（再次在代码中）谁可以对该构造执行什么操作，以及他们可以将其移动到哪些状态代码。