根据鲍勃叔叔/来源/，每个用户故事都应该有分离的“集成者/控制器”。听起来不错，因为班级很小并且只做一件事。
但在现实世界中，我没有看到以这种方式组织的建筑。如果有例如 AccountController，它总是包含与 Account 相关的所有方法。在鲍勃叔叔的“方式”中，这应该是这样设计的：
+Controllers
---+Account
------+DepositMoneyIntoAccount
------+WithdrawalMoneyFromAccount
------+TransferMoneyToAccount
或者我误解了鲍勃叔叔？但如果没有，你们中是否有人看到以这种方式组织的建筑？它在现实世界中实用吗？
问候
它当然是实用的，并且是大型复杂系统的绝佳工具。我将实体/边界/交互器（代替控制器以避免与流行的 Web 界面混淆）放在顶层目录中，并将整个通信系统放在子目录中（例如 z_rails、z_sinatra 等）。以 Rack 为例，使用各种通信框架交付 Web 解决方案非常简单，而且所需的额外工作最少。例如，查看 github.com/wizardwerdna/avdi 和 github.com/wizardwerdna/bobbit 以了解这些方面的初步实验。
你是对的，这就是他希望项目的样子。
记住他的演讲“架构：失去的岁月”，架构应该描述它的意图（还有什么比用例更好的呢？）。
一开始我也有点困惑，但如果我们考虑一下 BDD，其哲学就是要确保我们制作可理解的软件。
我看了几次视频，我可能会再看一次，因为它是一个新概念，需要学习。对我来说，最重要且更具挑战性的是为其他模块创建插件，他谈到了一个请求和响应模型，以保持前端和数据库等周围层完全独立于软件。
这样做的最终目标是我们的软件可以轻松替换任何插件，例如数据库或 UI。
我还想提一件事，我想你可能感兴趣。在最后的这次采访中，他透露他的下一本书将是关于我们现在正在讨论的这种新方法的全部内容。
更新
我在评论中看到您正在谈论调用具有边界，交互器等名称的包......
这完全没问题，在他的书中，一些开发人员在某些情况下使用模式名称来命名类或包的清洁代码......这是正确的，因为这是开发人员应该熟悉的技术术语。就像通过读取类的名称或包知道类是构建器或工厂一样，您可以知道交互器或边界是什么。根据干净的代码，这是正确的。