功能编程、领域驱动设计和测试/行为驱动开发

Question

我张贴是因为，首先，我想确保我对这3种方法的理解是正确的。第二，我想澄清一下它们是如何结合在一起的。我认为它们是用来解决不同问题的方法，而在我看来，它们似乎都应该很好地互补，因为它们解决了不同层次的抽象。

从我对函数式编程(Scala初学者)的很少了解来看，我认为函数式编程的目标是幂等的，而“真正的”函数应该只做一件事，而只有一件事(没有副作用)。

分离关注点(拥有UI、应用程序、域和基础结构层)，以及拥有一种无处不在的语言，并在开始实现之前与领域专家密切合作来理解当前的问题，从很高的角度来看，DDD需要做的最大的事情之一。

然后是BDD，它似乎是TDD的一种方法，它从DDD的某些方面(尤其是无处不在的语言和领域在设计和实现中的重要性)获得了一些启示，以便让测试驱动开发工作。

为什么我说它们是相辅相成的？简而言之：

1. TDD的支持者说，没有设计是必要的，让测试指导您的代码设计。但是，如果您使用BDD，您将在您的设计中使用领域知识，这与DDD有关。如果您以前做了一些像DDD那样的设计工作，那么您正在将您的解决方案空间从无限的缩小到有限的(并且是人性化的、平易近人的/可理解的)，这将有助于指导您的测试和设计。
2. 使用BDD，您的测试应该只测试一件事情，而函数式编程语言在这方面很棒，因为函数应该只做一件事，所以这可以帮助您设计您的函数，然后证明它们可以工作，因为您已经为它们编写了测试。
3. 因为函数只做一件事，所以它应该有助于实现关注点的分离。因此，如果您执行DDD (更高级别)，功能编程语言应该能够直观地实现设计(较低级别)，因为它执行了这些功能。

我对这些概念中的任何一个都是完全错误的，还是我说的有些道理？

Answer 1

1. TDD的支持者说没有必要设计..。

不，TDD的支持者说，允许在您的设计中进行测试只会改进您的设计。他们不会说你有一个很棒的设计，仅仅因为它是一个可测试的设计。

让我这样解释：

Testable == well designed? False
Testable -> well designed? False
Testable <- well designed? True

你必须设计周期。

为什么？因为一个好的设计不仅仅是可测试的。

1. 使用BDD，你的测试应该只测试一件事.

单元测试也是如此。BDD不仅仅是单元测试，TDD也是如此。

1. 因为函数只做一件事..。

f(g(x))可以是做两件事的函数h，一个是f，另一个是g。你把回一件事和做一件事混为一谈。

单一责任原则是“一件事”的来源。您可以在函数编程和面向对象编程中找到它。所有这些都不能使遵循这一原则变得容易。如果我不小心的话，我可以膨胀功能，也可以用不必要的垃圾处理其他地方的东西。

没有拐杖可以让你不必去想这件事。你必须记住它并遵循它，否则你会在任何范例中弄得一团糟。