探索与分享软件工程中的创新
自顶向下
自软件的开发进入高级语言时代后，就有一个对软件设计的基本原则——“自顶向下”。在面向过程的时代的自顶向下逐步求精是确保软件质量的一种手段。逻辑封装在过程中，或者说逻辑单元由每个过程去实现，这样各个逻辑单元建立的联系就形成一颗“树”。两个相关的逻辑单元形成串联。然而现实中体现的逻辑很复杂，两个逻辑单元的串联远远无法满足表达的需要，因此有了“Goto"语句。这是一个毁誉参半的功能。它简化了逻辑，但同时也破坏了逻辑的结构。而面向对象的诞生解决了逻辑表达的大问题，逻辑单元与逻辑单元之间有了更丰富的表达方式，而在本质上这种方法使逻辑单元之间联系所表达的关系仍然形成一颗“树”型，这种方法也比面向过程更加抽象。自然需要一些图例表达这样的关系，才能帮助人们理解整个结构。软件的缺陷就可能隐藏在这种抽象的关系中。
为了减化这种复杂性于是出现了MVC，MVVM，DDD等设计框架及设计模型。当发展到DDD（领域驱动设计）时，可以看到一个比较明显的层次结构。这一个层次模型比较清晰的表达了软件的结构，并使领域模型准确反映了业务语言，避免过早的关心业务数据之间的关系，因为以自顶向下为设计原则，那么自然是以业务逻辑规则决定业务数据的关系。当遇到一个复杂的业务，直接用领域模型反映业务语言吗？我认为这并不是明智的做法。
面对一个复杂的业务，我们将会面数十个或数百个类，类之间的关联会另人眼花缭乱。没有一种良好的管理方式它们其中很小一部分的变化都会使整个团队叫苦连天。而最简单有效的管理方式，我认为就是分层。这里借用了“AHP”(Analytic Hierarchy Process)层次分析法。这是一种实用的多方案或多目标的决策方法，是一种定性与定量相结合的决策分析方法。任何一个业务逻辑可以抽象为三个层次：“目标层”，“准则层”，“资源层”。目标层即业务逻辑所到达到的目的；准则层即业务逻辑目标受到的内外部约束和采取的措施和方案；资源层即实现业务逻辑需要的资源。如果业务逻辑复杂，还可以增加抽象层次。再以每个层次建立领域模型，形成一个多层次的业务描述。这样设计也将带来一些额外的好处。由于它引自AHP，通过数学模型可以计算出各层次的权重，为资源分配提供决策依据。
这样一个层次模型能显性表达变化的成本，越是处于底层的变化对模型的影响越大，变更所引发的成本也就越高也越是需要解耦合的设计。此时面向对象和它解耦合的设计才充分的显示出它的价值以及带来的便利。
上一章
[下一章]
