TDD 的想法很棒，但如果没有预先提出设计，我正试图围绕如何实现复杂系统。
例如，假设我有多个服务用于支付处理应用程序。如果前期没有可靠的设计，我不确定我是否理解开发将/可以如何跨多个开发人员进行。
如果有人可以提供一个示例和高级步骤来以这种方式组合一个系统，那就太好了。我可以看到 TDD 如何导致更简单、更健壮的代码，我只是不确定它如何将 1）不同的开发人员聚集到一个共同的架构愿景和 2）导致一个可以抽象行为的系统，以防止必须重构大量代码（例如，接受不同的支付方式或基于长期开发路线图的定价模型）。
我将重构视为生产系统中的巨大开销，其中数据模型更改会增加客户和公司的风险。
显然，我可能错过了 TDD 专家发现的一些东西....
恕我直言，这取决于团队的组成和风险偏好。
熟练的设计师能够以微小的步骤发展架构......如果你拥有它们，你可以在明确的设计阶段降低严谨性
TDD 可能需要一些前期设计，但绝对不需要前期大型设计。因为无论您在开始编写代码之前认为您的设计多么完美，大多数情况下它都不会通过 TDD 强制它的现实检查，并且会在您的 TDD 会话中途炸毁（或者您的代码会炸毁）如果您绝对想将其弯曲到您的原始计划）。
TDD 的巨大力量恰恰在于它让您的设计在您编写测试和重构时出现并完善。因此，您应该从小而简单开始，事先对细节做出尽可能少的假设。
实际上，您可以做的是与您的一对（或整个团队，如果您确实需要就您将要编写的内容达成共识）勾勒出几个 UML 图，并使用这些图作为起点你的测试。但是，一旦您编写了最初的几个测试，就摆脱这些模型，因为它们弊大于利，误导您坚持不再正确的愿景。
首先，我并不声称自己是 TDD 大师，但这里有一些基于您问题中的信息的想法。
我对上面 #1 的想法：正如您所提到的，您需要预先进行架构设计——如果没有这个，我想不出一种可以成功的方法。该架构为您的团队提供凝聚力和远见。您可能希望预先进行足够的设计，但这取决于您想要的敏捷程度。开发人员团队需要在开始编码之前知道如何将系统的各个组件组合在一起，否则这将只是一场大型黑客盛会。
如果有人可以提供一个示例和高级步骤来以这种方式组合一个系统，那就太好了
如果您正在组装一个由服务组成的系统，那么我将首先定义服务接口和它们将交换的任何消息。这定义了系统的各种组件将如何交互（这将是您预先设计的一个示例）。一旦有了这个，您就可以分配各种开发资源来并行构建服务。
至于#2；TDD 的优点之一是它在重构期间为您提供了一个“安全网”。由于您的代码包含单元测试，因此当您更改某些代码时，您很快就会知道是否有问题，特别是如果您正在运行持续集成（大多数人使用 TDD 方法）。在这种情况下，您要么需要调整单元测试以涵盖新行为，要么修复代码以使单元测试通过。
导致系统可以抽象出行为，以防止不得不重构大量代码
这取决于您的设计，例如使用策略模式来允许您抽象和替换行为。TDD 并没有规定您的设计必须受到影响。它只是要求您只做满足某些功能要求所需的事情。如果要求系统必须能够适应新的支付方式或定价模型，那么这就是您设计的重点。TDD 如果做得正确，将确保您满足您的要求并且您的设计是正确的。
我将重构视为生产系统中的巨大开销，其中数据模型更改会增加客户和公司的风险。
软件设计的问题之一是它是一个邪恶的问题这意味着重构几乎是不可避免的。是的，重构在生产系统中是有风险的，但是您可以减轻这种风险，TDD 将帮助您。您还需要有一个灵活的设计和一个低耦合的系统。TDD 将有助于减少耦合，因为您将代码设计为可测试的。编写可测试代码的副产品之一是减少了对系统其他部分的依赖；您倾向于对接口进行编码，从而允许您用模拟或存根替换实现。一个很好的例子是用返回一些已知数据的模拟/存根替换对数据库的调用——你不想在单元测试中访问数据库。我想我可以在这里提到一个好的模拟框架对于 TDD 方法是无价的（Rhino mocks和Moq都是开源的）。
我确信有一些真正的 TDD 大师可以给你一些智慧的珍珠……就我个人而言，我不会考虑在没有 TDD 方法的情况下开始一个新项目。