基于规则的业务流程分析

关注

VIP免费原创最新推荐文章于 2026-08-13 10:09:50 发布 901 阅读 AI 写同款· GEO 优化 ›

AI权益加码！Claude Code、Cursor等20+工具免费用！购周边限时加赠Coding Plan Lite，畅享主流AI工具！学习进阶更高效！阅读详情

“思考得少，瞎干得多”，就是目前企业开发的现状。瞎干了两个月后，回头来分析一下一个有趣的流程，是我们目前项目中最复杂的一个流程（因为要完成它而不能动脑，所以复杂）。

首先把UML书上的案例扔到一边，那个是齐全的菜谱、佐料、原料而真实项目是荒地。想想走到荒地上给自己整一顿满汉全席，不容易啊…… 现在已经忘了最初听到这个流程的描述是怎么样的了。大概就是“一个待办项会发送和接收很多次，也可以发送接收一次，发送完后就不能再次发送了，最后一个接收结束后才能结束整个流程”——够昏的吧^O^遇到这种事千万不能听客户、需求人员甚至项目经理的，架构师才是设计这个系统的人，不能自己分析、定义业务对象，下课去吧。

第一反应就是发送和接收必须是两个不同的待办项，随后是必须定义两个不同的动作：完全发送和部分发送。概念一定要区分准确。随后关于如何叫完全发送和部分发送有几次需求上的变化，但不影响流程的执行规则。

这个就形成了我在业务流程配置一文中写的ResponseTask类，当时的需求就是请求-接收，所以只写了两个Task；随后扩展成了每接收之后还有一个任务叫填写意见书，所有的意见书完成之后再开始一个新的任务。所以就改成了：请求-接收-响应三个操作，修改ResponseTask，增加了ResponseType这一枚举值属性，修改了结束的算法。目前的流程执行规则是相当死板的，完全硬编码在引擎内部，无法改变。以下是ResponseTask类和执行代码：

using System;

using System.Collections.Generic;

using System.Xml.Serialization; 



namespace Microsoft.Applications.ChinaMobilePMS.FlowEngine

{

    public class ResponseTask : TaskBase, IComparable<ResponseTask>

    {

        private int requestNumber = 0;

        private ResponseType responseMode = ResponseType.Request; 



        [XmlAttribute("RequestNumber")]

        public int RequestNumber

        {

            get { return requestNumber; }

            set { requestNumber = value; }

        } 



        [XmlAttribute("Mode")]

        public ResponseType ResponseMode

        {

            get { return responseMode; }

            set { responseMode = value; }

        } 



        #region IComparable<ResponseTask> Members 



        public int CompareTo(R