golang语言的办公工作流的包

https://github.com/js-ojus/flow

工作流——这个概念似乎有点重复，有些讲的的是程序内部的流程，有些讲的是办公工作流。

如果是后者，那么上述那个是不错的基础。

当然，我的meritms可以借鉴。

有道翻译的结果：

状态
流量正在缓慢地向释放，但是还不能使用!
流动
flow是一个很小的开源(Apache 2许可的)工作流引擎(golang)。
流是什么
作为一个工作流引擎，flow打算帮助定义和驱动“front office”<——>“后台”文档流。这种流动的例子有:
客户登记及核实详情，
分配给现场人员的工作及其后续工作，
审核和批准文件
故障单的生命周期。
flow在类型为“大型编程”的场景中提供了价值，尽管它在本质上并不是(目前)分布的。因此，它只处理编排，而不是编排!
flow——至少目前是这样——只支持图形化的机制(而不是层次化的)。
流的不是
flow是一个库，而不是一个完整的解决方案。因此，它不能被下载并部署为一个重新使用的服务。它必须由程序工作流定义和处理的应用程序使用。唯一的“小”语言支持是Go !当然，您可以在微服务体系结构中使用流，将其封装在一个瘦服务中。这可以使您使用您最喜欢的编程语言来驱动流程。
表达非目标
心流是小的!它显然不打算成为企业级的工作流引擎。因此，不支持从-导出到工作流建模格式，如BPMN / XPDL。同样，不支持像BPEL和wf - xml这样的可执行规范。真正的企业级引擎已经存在，用于解决复杂的工作流和互操作性，就像需要高端引擎一样。
流的概念
让我们熟悉最重要的概念和流动的部分。在阅读下面的内容时，强烈建议您在sql目录中读取数据库表定义，并在各自的*中读取相应的对象定义。文件。这可以帮助你更快地形成一种思维模式。
用户
流既不创建也不管理用户。它假定外部身份提供者负责用户管理。同样，流不处理用户身份验证，也不管理任务的授权，而不是流(pun打算)。
因此，流中的用户只能通过其惟一的id、名称和惟一的电子邮件地址来表示。身份提供程序还必须提供用户的状态:active和inactive。
团体
流，类似于大多数unix，隐式地为每个定义的用户创建一个组。这是一个单例组:它的惟一成员是对应的用户。
此外，可以通过将一个或多个用户作为成员来定义任意一般(非单例)组。用户与组之间的关系为M:N。
角色
允许给定文档类型的文档操作集，可以分组到角色中。例如，有些用户应该能够提出请求，但不能批准。另一些人应该能够批准或拒绝它。角色可以方便地对逻辑相关的权限集进行分组。
有关更多细节，请参见文档类型和文档操作。
访问上下文
访问上下文是一个名称空间，它定义授予用户和组的权限的权限。此类司法管辖区的例子包括部门、分行、成本中心和项目。
在访问环境中，给定的用户(尽管关联的单例组)或组可以分配一个或多个角色。在此访问上下文中，用户可获得的有效权限集是通过所有分配给该用户的所有角色授予的权限的联合，包括用户所包含的所有组。
文档类型
每一种文档都有一个独特的DocType，它由消费应用程序定义。文档类型是流程中的核心概念之一。它们作为其他几种实体的名称空间。
文档类型只是一个字符串。flow不会假定任何文档类型的细节。尽管如此，仍然强烈推荐在分级名称空间系统中定义文档类型。例如:
PUR:询价表
这可能意味着部门是‘采购’，而文档类型是‘请求报价’。作为一个变种,
PUR:奥德
可能意味着文档类型是“Purchase Order”。
文档状态
每一份文件都有不同的阶段。文档生命中可能的阶段被编码为一组特定于文档类型的DocStates。
文档状态只是一个字符串。flow不会假定任何文档状态的细节。
文档操作
给定一个特定状态下的文档，文档中的每一个合法行为都可能导致一个新的状态。DocActions枚举影响文档的可能操作。
文档操作只是一个字符串。流程并没有假定任何事情的细节