这是工作流式系统的良好设计吗?

我正在设计一个系统,它允许我将广泛的任务表示为工作流,通过IEnumerable方法公开它们的工作项。这里的目的是使用C的“yield”机制来允许我编写psuedo过程代码,工作流执行系统可以根据需要执行这些代码。

例如,假设我有一个工作流,其中包括在数据库上运行查询,并在查询返回某个结果时发送电子邮件警报。这可能是工作流:

public override IEnumerable<WorkItem> Workflow() {
    // These would probably be injected from elsewhere
    var db = new DB();
    var emailServer = new EmailServer();

    // other workitems here

    var ci = new FindLowInventoryItems(db);
    yield return ci;

    if (ci.LowInventoryItems.Any()) {
        var email = new SendEmailToWarehouse("Inventory is low.", ci.LowInventoryItems);
        yield return email;
    }

    // other workitems here
}

checkinventory和emailwarehouse是从WorkItem派生的对象,WorkItem具有子类实现的抽象execute()方法,封装了这些操作的行为。在工作流框架中调用execute()方法-我有一个WorkflowRunner类,它枚举工作流(),在工作项周围包装前后事件,并在事件之间调用execute。这允许使用应用程序在工作项之前或之后执行所需的任何操作,包括取消、更改工作项属性等。

我认为,所有这些的好处在于,我可以用负责完成工作的工作项来表达任务的核心逻辑,并且我可以以一种相当简单、几乎是程序化的方式来完成工作。另外,因为我使用的是IEnumerable和支持它的C语法糖,所以我可以组合这些工作流,比如使用和操作子工作流的高级工作流。例如,我编写了一个简单的工作流,它只是将两个子工作流交错在一起。

我的问题是,这类架构是否合理,特别是从可维护性的角度来看?对于我来说,它似乎实现了几个目标——自我记录代码(工作流按程序读取,所以我知道什么将按什么步骤执行)、关注点分离(查找低库存项目不依赖于向仓库发送电子邮件)等等——我没有看到这种架构有什么潜在的问题吗?最后,这个以前试过吗-我只是在重新发现这个吗?