接演前文，我们这个任务是找到描述“特征”这个业务的语言——就是DSL，其实也就是找个合适的形式来写配置。不错，让我们看看如何找这个合适的形式。

前文已经说过，对这个DSL的形式，我们有几个要求：

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

我们一一来看这些要求：

• 动态的：比较容易做到。我们只要不把配置放在静态的配置文件就可以了。放入数据库，或者可读写的文件系统都可以。主要涉及到DSL的管理、使用问题，与DSL本身的结构没有多大关系。
• 容错的：稍微难一点。但我们只要对每个DSL段修改后运行一个校验方法，在一个DSL段导入到系统之前，对它进行校验，给出错误信息就可以了。
• 全局的：更难一点了。回想一下前文介绍的“特征“的定义，它就是DSL要描述的对象。这个对象比较复杂。

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

  一个特征，包括了业务差异、扩展点、扩展，有好几个方面的信息。要把它们放入到同一个DSL片段（比如一个文件或一条数据库记录）中，除了各个方面的体量都不能太大，还得适当地表达出它们之间的联系。如果片段总体体积很大，超出了人们的阅读能力，或者人们阅读的时候，需要跟着很多引用、指针之类的到处跳来跳去，那显然我们的全局性要求就没有达到。

• 可读的：很难。正如前一点要求提到的，我们需要正确地表达出扩展点、扩展这些信息。如果仔细想一下就能意识到，扩展点与扩展点、扩展与扩展，可能是非常不同的。比如有个扩展点，是决定一个文档中有哪些字段的，另有一个扩展点，是决定一个文档在某个状态下可以被采取什么动作的。这些东西风马牛不相及，需要描述的内容非常不同，要如何才能给它们一个统一的描述形式呢？

全局和可读，是我们这个DSL设计要重点解决的问题。