我今天正式开始编写互动平台的代码。我想让CD负责Flex界面一块，而自己编写所有的后台程序。这是一个尊循XP原则的TDD开发。
我获得的是早先安排CD编写BBS需求报告，他在需求报告中列出了一个他所看到的BBS应该具有的各种功能。尽管这个报告能够对我的开发起到驱动作用之前我仍然要花费大量的时间去整理，但是还是可以从这个报告中逐步抽取素材来实现TDD。我优先选择了用户操作的功能，整理了二十多条US作为第一迭带期的任务。
在开发之初，显然需要说明的是我对TDD的做法并不是很熟练。但是我觉得XP是应该可以从任意原点出发的（目前还在证明这一点）。因此，我很任意地抽取了第一个US：用户注册。
首先我意识到显然需要一个User类，然后还有register方法。我快速地写完了一个可能并不正确的测试，进一步地，为了测试通过我建立了这个类和相应的方法。JU变绿了。下一步的重构，让我足足考虑了十分钟。我认为这个Register方法内部应该是一个空的壳子。因为US上既没有要求我处理用户输入、也没有要求我存储用户，更没有说应该处理哪些异常及怎么处理。一个BO方法中，要么就是在根据业务规则处理相关的数据，要么就是将任务委派给他的层次去执行（比如持久化服务层），要么就是在处理意外情况。我实在想不出还有什么操作能够在一个BO方法中出现。
但是，我又说服不了自己TDD出来一个空的Register。我想这个Register应该会带来些什么。考虑一个隐喻，如果BO方法实际存在，那么Reigeter的功能大概就是将BO对象中的数据按照Register的业务要求进行验证，然后送入服务层去持久化，最后处理意外情况，或在没有意外的时候根据要求返回控制。因此，在制作Register的方时，我们确实可以看看这个BO里的字段（数据）应该以和面目存在。我继续隐喻。于是在需求中发现一段关于用户数据由哪些具体的字段组成的要求。于是，我放下User.regiseter。快速建立了一个POJO – UserBean。
这个UserBean是一个纯粹的POJO符合JavaBeans标准。我把它放在一个新的包中，接下来的一分钟里，我开始说服自己建立一个构架。也就是说，BO相关的数据全部抽取到DataTransferObject这个新的包中，作为数据传输层。而BO层与这个传输层的关系是BO里的BO类实用DTO里的DTO类。例如User这个BO类使用UserBean。
为什么我能够把构架的想法放进去呢，很简单因为两个原因：1、我觉得需要，2、我觉得能够很简单就实现。所以我这么做了。
有了这个DTO后，我发现了意外的收获。当我返回去完成User那个重构的时候，我很自然地在Setup和tearDown里面去创建了一个UserBean，然后把UserBean设置到User里面去。原来的testRegister()没有动，User的register方法也仍然空着。但是一切都很好，只等着那些要求持久化User和要求注册界面的那些US了。
现在我在一个新的构架上继续TDD。在继续下去之前，我试图理解一个问题。既然是TDD那么为什么会有不经过测试而直接建立UserBean这样的事情发生呢？我最后的答案是：谁会想去测试一个setter/getter的POJO呢？当然非要TDD也可以，但是很明显的事情，且完全落在US的要求内（步子不大）的情况下，无任何必要这样做。
到了晚上，和Q交流了一下白天做的事情。Q对于我那个register()存在两个问题：一是为什么User类会有register方法，二是为什么不是register(userData)。
对于第一个问题，我的回答是，因为Register操作的数据位于User中，因此Register这个职责暂时就这么分配了。当然User的register可能并不是系统中用户注册功能的发起者，也不可能是具体持久化的执行者，肯定是一个委派链条的中间环节。无论如何，根据那个US我只能作出这样的抽象和这样的职责分配。
对于第二个问题，我是这样看的。(new User(userData)).Register();给人的感觉是，User实际存在了，只是目前还没有证实倍系统确认，现在让他Register()一下。而(new User()).register(userData)给人的感觉是，那个User只有驱壳没有灵魂，调用register(userData)就仿佛在说，我只有驱壳，没有灵魂，要是让我有血有肉的话，那么让我的驱壳去把我的灵魂注册一下吧。
