ボブおじさん/ソース/によると、すべてのユーザーストーリーは「インテグレーター/コントローラー」を分離する必要があります。クラスは少人数で、たった1つのことをするので、いいですね。
しかし、現実の世界では、アーキテクチャがそのように編成されているのを見ていませんでした。たとえばAccountControllerがあった場合は常に、Accountに関連するすべてのメソッドが含まれていました。ボブおじさんの「道」では、これは次のように設計する必要があります。
+Controllers
---+Account
------+DepositMoneyIntoAccount
------+WithdrawalMoneyFromAccount
------+TransferMoneyToAccount
または多分私はボブおじさんの誤解ですか？しかし、そうでない場合は、誰かがこの外観でアーキテクチャが整理されているのを見たことがありますか？実世界で実用的ですか？
よろしく
それは確かに実用的であり、より大規模で複雑なシステムのための優れた手段です. エンティティ/境界/インタラクター (一般的な Web インターフェイスとの混同を避けるためにコントローラーの代わりに) を最上位のディレクトリに配置し、通信システム全体をサブディレクトリ (z_rails、z_sinatra など) に配置しました。たとえば、Rack を使用すると、さまざまな通信フレームワークを使用して、最小限の追加作業で簡単に Web ソリューションを提供できます。たとえば、github.com/wizardwerdna/avdi と github.com/wizardwerdna/bobbit を見て、これらの線に沿った初期実験を行ってください。
あなたは正しいです、それは彼がプロジェクトをどのように見せたいかということです。
彼の講演「アーキテクチャ：失われた年」を思い出してください。アーキテクチャはその意図を説明する必要があります（そしてユースケースよりも優れているのでしょうか？）。
当初、私も少し混乱していましたが、BDDについて考えると、哲学は、理解しやすいソフトウェアを確実に作成することを望んでいます。
私はビデオを数回見ましたが、それは新しい概念であり、研究が必要なため、おそらくまた見ます。私にとって最も重要で難しいのは、他のモジュールのプラグインを作成することです。彼は、フロントエンドやデータベースなどの周囲のレイヤーをソフトウェアから完全に独立させるために必要な要求と応答のモデルについて話します。
これの最終的な目標は、当社のソフトウェアがデータベースやUIなどのアドオンを簡単に置き換えることができるようにすることです。
もう1つ言いたいのは、あなたはおそらく興味があると思います。最後のこのインタビューで、彼は次の本が私たちが今議論しているこの新しい方法論についてのすべてであることを明らかにします。
アップデート
コメントで、Boundaries、Interactorsなどの名前のパッケージを呼び出すことについて話していることがわかります...
これは完全に問題ありません。彼の本のクリーンなコードでは、一部の開発者がクラスやパッケージに名前を付けるためにパターンの名前を使用することがあります...開発者が精通している必要があるのは技術用語であるためです。クラスの名前やパッケージを読み取ることで、クラスがビルダーまたはファクトリであることを知るのと同じように、インタラクターまたは境界が何であるかを知ることができます。クリーンなコードによれば、それは正しいです。