如何将TDD与DDD结合起来，最近在看TDD（测试驱动开发的艺术），也按照书中例子尝试了一些，然而思维仍然很混论。感觉上无法很好的调和DDD和TDD，大体上感觉TDD应该遵从DDD中的原则和约束应用到代码中，然而这两者之间的过渡仍然不甚明了，如何将DDD渗入到TDD中，使用了TDD，直接从用户的需求中进行测试先行开发，而领域模型的构建则是为了验证和获取需求？领域建模的目的就在于获取和映射现实需求?可是一直以来觉得领域设计多少是有一些职责的确定等等在内的。在TDD中，确定一些测试用例，该使用那些测试，觉得也是在“无形”的使用DDD中的某些思想或或者信息，但是具体又说不太清楚。感觉好像两者交织在一起。希望有经验的给予解惑，谢谢。
意思不要拘泥于原来的TDD测试，可以对领域模型进行单独测试，使用基于领域事件的行为驱动方式，最后通过集成测试模拟客户端发出命令对领域层进行测试。
谢谢banq的回复。对于TDD，我在最近思考后觉得还是有一定道理，更多的觉得对于我们传统的领域驱动设计，可能在分析出用例图后，初步构建出领域模型，然后我一般会尝试着画出序列图（表达类之间的协作交互），而使用TDD似乎就是将这一步直接用测试来替换。至于在TDD社区中的看到的那些，或者书中的事例也好，发现无异于他们已经”知道“功能或着"需求”，直接为了完成某项功能。我只是将tdd看做了一种探索系统内部实现方式的一种手段，至于需求的获取，如何知道客户做什么，我觉得还是得领域模型的设计（当然设计多少这个根据个人经验和对此领域熟悉程度而定）。基于领域事件的行为驱动方式，感觉思想很好，只是一直还没有具体实现过。下去会慢慢探索尝试使用看看。
测试驱动也能很好地发现客户的需求。
例如客户说，我要求软件有这么个功能，我一点按钮A，就能找出来去年参加审批但今年没参加的。我们就可以编写一个测试用例
List<Company> withLastYearButWithoutThisYear() {
throw new BusinessException();
}
然后客户又说要这么个功能，想要点一下按钮B，就能给已经是4星，并且连续3年都参加审批的企业升级成5星。可以再编写一个测试用例
void upStarWith4StarAnd3YearReview() {
throw new BusinessException();
}
这些用例一开始都是红的，只有全变绿了才能说功能开发完了。
当然软件内部的一些测试也不能少，最常见的像表单验证，值过滤，除数非零之类的，算不上关键功能但也必不可少。这些测试是为了今后维护时一旦改动结构，仍然能保持软件可用，比如有人想将一个数值类型的金额变为字符串类型，希望直接在前面加人民币符号或者美元符号，如果文档里没有描述出这个字段的类型，他也不知道能不能改，但一运行测试是红的，就知道这里必须要求一个数字类型了。