返回本文：

     所谓变动自由度，就是改变底层模块的接口(Interface)时，是否会引发许多修改点，而导致牵一发而动全身呢? 如果是这样的话，变动成本提高了，变动自由度也下降了。

Step-1.反思：模块开发者自己定义模块的接口，这是一种假设(Assumption)，不是真理。如果建造地基的人自己决定地基的接口，然后开放给上层未来可自由搭建房子；表面上是合理的，其实不然。

Step-2. 衍生出一个假定(Hypothesis)：欲建造一间房子，它有四根柱子，分别由四个人各建造其中的一根柱子，然后各自定义其柱子接口。基于事实，由于各自对未来整体房子的想象不尽相同，其接口定义会不一致，那房子就很难建好了；于是否证了这项假定。这就是著名软件专家Brooks在40年前写的<<人月神话>>一书里所说的：设计的”概念一致性”(Conceptual Integrity)。缺乏了一一致性，将失去整体性；架构师的核心职责就是要促进设计一致性，以确保架构整体性。

Step-3.需求冲突：

l模块开发者必定(must)自己来设计和定义模块接口。

l架构师必须促进接口设计和定义的一致性，以确保架构整体性。

Step-4.架构师设计一个模式(Pattern)来化解需求冲突

4.1 标准接口模式：架构师统一制定标准接口，让四个开发团队来遵循开发；如下图：

    这样有个缺点，很可能会违背第一项需求，原因可能来自模块的专业知识，或其它商业利益因素。也就是说，模块专业知识或其它商业优势条件的原因，必须由模块开发者自己来设计和接口；导致这个模式就不可行了。此外，很可能会冻结未来的弹性变化空间；因为这个标准接口的使用点会分散于”房子系统”的多个角落，局限了标准接口的未来变动空间；兹设想，未来如果标准接口变成不标准时(由于技术变迁等因素)，有需要更改这个”标准”接口时，由于使用点分散各处，将产生牵一发动全身的涟漪效应，变动成本急速上升，就冻结了接口和模块的未来变化空间，降低其变动的自由度。

4.2 通用性接口模式：架构师制定一个通用性接口，而四个开发团队可各自定义其模块的特殊性接口。

    然后，透过EIT造形来衔接和转换这两项接口。

   这个EIT造形可实现如下：

    架构师制定和掌握通用性接口，包容各开发团队的特殊性接口，让各根柱子的接口和建置都能保持未来性，确保具变动的自由度。也有效化解上述的需求冲突了。