设计这套DSL的过程中，一直纠结的是：这到底是不是真正的DSL？

这套DSL，是为公司办公系统的“特征机制”设计的。

所谓“特征”，是对业务差异的一个建模。

我们的办公系统同时为多个不同的业务机构、外部系统、不同的文档类型服务，不同的机构、不同的外部系统、不同的文档类型带来了不同的业务差异逻辑。 这些差异化的业务逻辑，带来了系统大部分的复杂性、不稳定性。 处理通用逻辑与差异逻辑的关系，成了我们这个系统架构的主要挑战之一。 应对的原则很明确，就是将差异逻辑与通用逻辑分开，使其互不影响，分别进化。 架构上典型的模式——按通用性分层。

“特征机制”就是我们对这个模式的一个实现，简述一下：

• 我们把系统逻辑中可能发生扩展的点称为扩展点。
• 不同的业务差异，通过在扩展点上填入适当的扩展来实现专用逻辑。
• 所谓特征，就是一条知识，描述了当在何种业务差异的处理中，需要在哪些个扩展点填入哪些个扩展。
• 所谓特征机制，就是当系统运行到一个扩展点的时候，查找到正确的特征，填入正确的扩展并运行的机制。

容易发现，特征机制要发挥作用，需要有一个机制来描述所有的特征，这就是特征机制的知识层，对这个描述机制要求是：

• 全局的：我们希望一个特征的所有内容，能够一次看到。如前所述：

  一条知识，描述了当何种业务差异的情况下，需要在哪些个扩展点填入哪些个扩展。

• 动态的：可以在系统运行中加入、删除或者修改一个特征。
• 可读的：我们希望运营人员甚至业务人员可以看懂并修改这些特征。
• 容错的：系统能帮助修改者发现并改正描述中的错误。

这些要求并不容易，幸好我们设计这个机制的时候已经将知识层与操作层分离，可以分别进化。先做好操作层，保证机制可以运行，后续再逐渐改善简陋的知识层。目前的知识层，是spring bean配置文件，整个特征机制可以运行，但上述的描述机制要求一条也没有达到。

于是便有了这一场DSL。