和Thoughtworks的一次邂逅（一） Thoughtworks富血模型DDDTDD

 

虽然最终没能去Thoughtworks，也遇到了一些不愉快，但是内心还是很尊敬Thoughtworks。其实一切都很顺利，直到谈offer之时。以下是我的个人经历：

 

在找工作之际，thoughtworks居然给我打来电话，说51job上看到我的简历对我感兴趣，估计是我出版书籍的原因吧，对于这个公司，我一直很敬仰，于是就开始接下来的面试。

 

刚开始，就发了3道题目过来，让我挑选一个做完，我选择了一道最熟悉的（实在抱歉，不能透漏其中试题），做完发了过去，忘记了把测试代码发送过去了（后来才知道），测试代码对于他们来说是很重要的，因为他们习惯使用TDD进行开发，而我习惯于DDD进行开发，而这的区别我会在接下来的博客做个粗浅的比较。

 

我周日提交的代码，过来大概3-4天吧，突然看到有个北京的号码打过来，却没有接到，我打了过去，谁知道是总机号码，于是hr邮件里的打手机，却是处于关机状态。我想算了吧，反正也不知道结果如何，这时才想起测试代码没有打包过去。直到第二天下午吧，终于接到电话，说这几天总是联系不上我。听完心里还是窃喜，说明那段代码还凑合。

 

于是安排了电话面试，说是40分钟左右，其实面试了大概70多分钟，考察了些设计方面的东西。这里详细说明一下，现在觉得还是很感兴趣。

 

我们谈到了一些富血模型方面的问题，不过他们提到要在领域模型里加入Save方法（这个可能是受RoR的影响，RoR对于复杂领域方面，处理能力还是相对偏弱的），这样，领域模型就依赖于Repository，这个我不太赞同，不过感兴趣的是他们提到了使用Visitor模式实现这个save方法。这个其实个人觉得这个不太合适，一方面会把Service逻辑放入领域模型甚至Repository中，另外，这些类的粒度会有问题，他提到一个基本的Repository类有save方法，还有一个除过基本的save操作外，还要加入报表的逻辑。因为我是做DDD，个人认同Eric Evens（写DDD的大牛）的观点，因为目前来讲，数据库技术里的差异性和数据库的伸缩性等特点，以及我们存储数据的不确定（可以是传统数据库RMDB，），导致

 

 

后来说是安排在上海面试我，但是找了几个时间，他们上海的工程师那边始终凑不起来（说要三个工程师），后来说直接让我去北京面试，其实，这里便埋下了不愉快。

 

那天是周一，上海天气还是阴沉沉的，那几天又感冒，状态很差，甚至于半夜都要起来服咳嗽药，休息了两个礼拜天后，5点钟起来踏上了面试的征程……

 

 

时间不早了，未完待续……