这是一个工作流程式系统的优秀设计吗？

我正在设计一个系统,允许我将广泛的任务表示为工作流,通过IEnumerable方法公开他们的工作项.这里的目的是使用C#的'yield'机制来允许我编写工作流程执行系统可以在其认为合适时执行的伪程序代码.

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

public override IEnumerable 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的对象,它具有子类实现的抽象Execute()方法,封装了这些操作的行为.在工作流框架中调用Execute()方法 - 我有一个WorkflowRunner类,它枚举Workflow(),包围工作项的事件前和事件后,并在事件之间调用Execute.这允许消费应用程序在工作项之前或之后执行它所需的任何操作,包括取消,更改工作项属性等.

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

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