根据bob/source/叔叔的说法，每个用户故事都应该有单独的"积分器/控制器"。这听起来不错，因为课程很小，只做一件事。

但在现实世界中，我没有看到这样的建筑结构。如果有会计控制器，它总是包含与帐户相关的所有方法。在Bob叔叔的"方式"中，应该这样设计：

或者我误解了鲍勃叔叔？但如果没有，你们中有人看到这种结构吗？它在现实世界中很实用？

当做

它当然是实用的，对于更大、更复杂的系统来说是一种很好的工具。我将实体/边界/交互程序(控制器的实例，以避免与流行的Web界面混淆)放在顶级目录中，并将整个通信系统放在子目录(如z ou Rails、z ou Sinatra等)中。例如，对于Rack，使用各种通信框架以最少的额外工作交付Web解决方案非常简单。例如，请查看github.com/wizardwerdna/avdi和github.com/wizardwerdna/bobbit，了解沿着这些线进行的初始实验。

你是对的，他希望这个项目看起来像这样。

记住他所说的"架构：逝去的岁月"，架构应该描述它的意图(还有什么比用例更好呢？).

一开始我也有点困惑，但如果我们考虑它，BDD，哲学想要确保我们使可理解的软件。

我看了几次视频，可能会再看一遍，因为这是一个新概念，需要学习。对我来说，最重要和更具挑战性的部分是为其他模块创建插件，他谈到了保持前端和数据库等周围层完全独立于软件所需的请求和响应模型。

最终的目标是我们的软件可以很容易地替换任何插件，如数据库或用户界面。

我只想再提一件事，我想你可能感兴趣。在最后的采访中，他透露他的下一本书将是关于我们现在讨论的新方法论的。

更新

我在评论中看到了你所说的调用带有名字的包，比如边界、交互程序…

这完全可以，在他的书《干净的代码》中，一些开发人员在某些场合使用模式的名称来命名类或包…这是正确的，因为开发人员应该熟悉技术术语。以同样的方式，通过读取类的名称或包，您可以知道类是一个构建器或工厂，您可以知道什么是交互或边界。根据清洁代码，这是正确的。