重新审视演进式设计

说起来，所谓Evolutionary Design已经是老生常谈了。早在2004年，Martin Fowler在文章Is Design Dead中就深刻地比较了计划式设计与演进式设计，至今阅读这篇文章，对于理解敏捷和演进式设计依旧振聋发聩。我在博客设计恰如其分的架构中，也算得上是旁征博引地阐述了诸多与演进式设计相关的理念，例如Neal Ford提出的Emergent Design，George Fairbanks提出的Risk Driven Design，以及Minimal planned design。

然而，有多少人在遵循着Evolutionary Design的理念进行着架构的规划与设计呢？如果说，架构过程确定无疑地需要不断地演进，但该如何演进，如何更好地演进，依旧是一个巨大的谜题。Neal Ford提出的诸如发现模式、重构、测试驱动开发等方法，更多地还是停留在微观架构的层面。而在多数的架构设计过程中，更多地是基于质量属性，前瞻地去选择架构风格（抑或架构模式），并参照一些最佳实践结合自己的场景去驱动出物理架构与逻辑架构。若完全寄情于Last Responsible Time，期待着通过对架构重构让已有软件系统焕然一新，毕竟代价太大，对架构师的能力也要求太高。

正如Martin Fowler对架构的定义：

架构是重要的事物，无论它是什么。架构是以后很难更改的内容。

既然很难更改，我们为何不能一蹴而就？然而，Neal Ford又告诉我们：未来是不可预测的。于是之，我们并不能以无知的未来妆点当下，否则会导致设计过度，甚至南辕北辙。虽然一路向北，终究能返归南方，可惜路漫漫其修远兮，没有人愿意等待，也不值得等待。

在Agile China 2013年，我在ThoughtWorks的同事Scott Shaw与贾阳联袂演出了一台戏，戏名唤作Evolving Architecture For Change，以一个真实案例阐释我们如何演进客户系统的架构。演讲从Evolving Path、Technical Enables与Culture Enables三个方面全面细致地介绍了架构的演进之路。概而言之，用到的方法与理念包括：

演进之前的架构是一个简单分割的分布式架构，Front End面向客户的用户，而Office End则面向业务人员和系统管理者。整个系统的模块边界非常模糊，集成复杂，代码库庞大而混乱，存在大量重复代码。

采用上述方法对系统架构进行演进，最终形成了如下图所示的基于RESTful的围绕Domain Service为中心的类微服务架构：

然而，严格意义上讲，这个案例的架构演进属于针对已有系统（或遗留系统）架构进行重构的范畴，而非从头开始搭建架构的演进式设计。

最近读到Joshua Kerievsky的文章Evolutionary Design，他提倡架构设计从Primitive Whole开始，勿求功能做到最深最全，而是以“广度优先”的算法思想在最初的设计中覆盖整个系统的全部组成部分。如下图所示的吉他设计：

迭代1设计的吉他根本不可用，但基本的组成元素已经初具模型，虽然它不能工作，但任何人看到这个模型，也不会认为它是小提琴或者二胡。

如此设计的好处在于可以提前发现团队协作与组件集成的风险。因为前期迭代的功能铺得极广，就像八爪鱼一般延伸到了系统的每一枝节（这些枝节却没有一片树叶），虽然极度粗糙简陋，但团队已经可以开始协作开发，系统的集成点也被提前发现了。

协作问题是管理风险，集成问题是技术风险，二者都是导致软件开发延期的主要魁首。虽然只是迈出了第一步，但这一步迈得扎实，迈得稳当，之后就可以以更加稳健步伐前进，庶几实现“较少修改”的架构。

我发现这个阶段是引入Alistair Cockburn六边形架构(Hexagonal Architecture)的最佳时期。

运用六边形架构可以有效地识别系统关注点，从架构层面（全局视角）设计，暂时可以不考虑实现细节。六边形架构这种内外分离的方式，可以有效地把系统的核心领域与边界外的基础设施隔离开，从而形成一种独立于框架，易于测试，与外部代理、UI以及数据库无关的应用架构（符合Robert Martin提出的Clean Architecture）。与演进式设计结合起来，可以很好地帮助我们识别集成点，以更广而非更深地视角俯瞰系统架构。

演进式设计是一种理念，它曾经颠覆过传统笨拙的计划式设计，如今，它依旧焕发着生命力，但我们不能以静止的眼光去看待它，而应该尝试着引入一些新的方法、框架乃至技术——于是，演进式设计这旧瓶就能装着新酒，既散发出酽酽的酒香又不至于浓洌得熏人欲醉！

posted @