FitNesse案例：通过划边界层层推迟数据库决策的真实历程

与[[P公司与W公司的悲伤故事草率架构决策的真实代价]]相反的成功案例，是作者本人和儿子2001年创立的FitNesse公司。他们给自己定了一条”下载即可执行”的铁律——用户不该被要求下载超过一个jar文件，这条规则驱动了后续一连串决策：先是自己写了个只含基本功能的简易Web服务器（而非用现成开源方案），因为部署简单、还能把具体Web框架的选择往后推；接着是刻意采用与数据库无关的设计，把所有数据访问逻辑收进一个叫WikiPage的接口（负责查找、获取、保存页面），最初这些方法只是占位实现，开发wiki文本转HTML这类不涉及数据存储的功能时用一个叫MockWikiPage的空实现顶着。当占位方法撑不住实际需要的功能时，才真正实现数据访问——先做了个InMemoryPage派生类，用内存哈希表管理wiki页面，这样开发了整整一年，第一个能跑的FitNesse版本已经能创建页面、链接页面、跑wiki格式装饰、用FIT工具跑测试，唯独不能真正持久化数据。到真要考虑持久化时，团队权衡后觉得没必要上MySQL，因为把哈希表写入文件足够简单，于是做了个FileSystemWikiPage，用单一大文件实现持久化——三个月后确认这个方案已经够用，MySQL这个决策就这样被一路推迟到”发现根本不需要做”。直到一位客户出于自己需求想把数据存进MySQL，团队向他展示WikiPage架构细节后，他只花了一天时间写了个MySQLWikiPage派生类就实现了。这条在业务逻辑和数据库之间早早画下的边界线，让FitNesse团队推迟数据库选型和实现整整一年多，期间可以用文件系统自由实验，18个月的开发周期里完全不用面对表结构、查询语句、数据库服务器、密码、连接超时这些棘手问题，所有测试因为不依赖数据库而跑得飞快——需求真的出现时，这套架构也没给采用MySQL制造任何障碍。