程序思维模型和领域思维模型

在工作站中，我实现过一个任务模块（为方便解说，以下作了部分简化）。

任务分为三种：

• 简单类型：由一系列单一的任务条目组成。对所有的任务条目按照从上到下的顺序执行一次，任务便会结束。
• 组类型：也是由一系列单一的任务条目组成。但可以循环执行多次。用户可以设定循环的间隔时间。
• 复合类型：简单类型和组类型的任意组合。

任务条目可以包含多个任务项，这些任务项按照从左到右的顺序执行。用户可以设定任务项的间隔时间。

有一天，我们的应用工程师问我任务“组”有什么用。

我简单地回答说，它可以实现多个任务条目的循环执行。

应用工程师表示不理解。

我于是新建了一个任务组，添加了任务条目A、B、C，继续解释说，一般的情况下，ABC执行一次就完了；但在某些情况下，需要对ABC进行反复地执行，就是说，在C执行完毕后，又需要从头再次执行一遍或多遍ABC。

应用工程师点了点头，但还是有点疑惑，继续问：那它在实际中到底能干点什么具体事务呢？

我立即蒙了。我只是一个小小的程序员，一个具体（设计）需求的实现者，我可以解释实现的具体过程，但如何知道它能够解决的具体的业务呢？当然，可以看看相关的文档，找找原始的业务需求。可惜我们没有文档。

最后只好询问头头这个精通业务的人。他解释说，气象部门会对每天的空气质量进行测试；今天早上会在8点和9点测试一次，明天早上也会在8点和9点测试一次，每天早上都会会在8点和9点测试一次。在这种情况下，我们就可以使用任务组。该任务组只需要一个条目，这个条目拥有两个任务项。这两个任务项对应8点和9点的测试。因此，它们的间隔时间需要设置为1小时。显而易见的是，任务条目应该每天执行一次。也就是说，9点的测试执行完毕的23小时后，继续执行8点的测试，然后在一小时后，执行9点的测试；再等待23小时......如此反复。对于气象局的工作人员来说，只要在第一天的8点准时启动任务组就可以了。

头头描述了可以用任务组解决的一个具体的业务，而应用工程师懂业务。

我描述了任务组运行模式或者说叫规则。但我不懂业务，不知道这套规则可以解决哪些实际的问题。因此，应用工程师不会从我这儿获得满意的答案。

应用工程师倾向于实际的问题，倾向于现实的世界。我，一个程序开发人员，则倾向于问题解决方法的实现模型，倾向于计算机的世界。

这两个世界对应开发中的两个阶段，它们中间还差着一个概要设计。也就是说，我和应用工程师处在两个完全不同世界，因为语言不通而无法实现有效的对话。