回答:
あなたが言及したフォルダについて：
/libs 通常はカスタムに使用されます classes/functions/modules/vendorまたは/supportサードパーティライブラリが含まれています（gitをソース管理として使用する場合はgitサブモジュールとして追加されます）/spec BDDテストの仕様が含まれています。/testsアプリケーションの単体テストが含まれています（テストフレームワークを使用。ここを参照
）注：両方/vendorと/supportNPMは、クリーンなパッケージ管理を導入しましたので、廃止されました。NPMとpackage.jsonファイルを使用して、すべてのサードパーティの依存関係を処理することをお勧めします
かなり大規模なアプリケーションを構築するとき、私は（あなたのようなMVC- / ORMフレームワークのいくつかの種類を使用している場合は特に、次の追加のフォルダを推奨明示またはマングースを）：
/modelsすべてのORMモデルが含まれています（Schemasマングースで呼び出されます）/views ビューテンプレートが含まれています（Expressでサポートされているテンプレート言語を使用）/public すべての静的コンテンツ（画像、スタイルシート、クライアント側JavaScript）が含まれています
/assets/images 画像ファイルが含まれています/assets/pdf 静的PDFファイルが含まれています/css スタイルシート（またはcssエンジンによるコンパイル済み出力）が含まれています/js クライアント側のJavaScriptが含まれています/controllersアプリケーションのモジュール/エリアで区切られたすべてのExpressルートを含みます（注：Expressのブートストラップ機能を使用する場合、このフォルダーはと呼ばれます/routes）私はこの方法でプロジェクトを整理することに慣れており、それはかなりうまくいくと思います。
CoffeeScriptベースのExpressアプリケーションの更新（connect-assetsを使用）：
/app コンパイルされたJavaScriptが含まれています/assets/ コンパイルが必要なすべてのクライアント側アセットが含まれています
/assets/js クライアント側のCoffeeScriptファイルが含まれています/assets/css LESS / Stylusスタイルシートがすべて含まれています/public/(js|css|img) どのコンパイラーでも処理されない静的ファイルが含まれています/src サーバーサイド固有のすべてのCoffeeScriptファイルが含まれています/test すべての単体テストスクリプトが含まれます（選択したテストフレームワークを使用して実装）/views すべてのエクスプレスビューが含まれます（ヒスイ、ejs、その他のテンプレートエンジンなど）次のような質問があるため、GitHubでディスカッションがあります：https : //gist.github.com/1398757
他のプロジェクトをガイダンスに使用したり、GitHubで以下を検索したりできます。
そして最後に、本（http://shop.oreilly.com/product/0636920025344.do）はこの構造を示唆しています：
├── index.html
├── js/
│ ├── main.js
│ ├── models/
│ ├── views/
│ ├── collections/
│ ├── templates/
│ └── libs/
│ ├── backbone/
│ ├── underscore/
│ └── ...
├── css/
└── ...私のプロジェクトアーキテクチャからのより多くの例はここに見ることができます：
├── Dockerfile
├── README.md
├── config
│ └── production.json
├── package.json
├── schema
│ ├── create-db.sh
│ ├── db.sql
├── scripts
│ └── deploy-production.sh
├── src
│ ├── app -> Containes API routes
│ ├── db -> DB Models (ORM)
│ └── server.js -> the Server initlializer.
└── test基本的に、論理アプリはSRCディレクトリ内のDBフォルダーとAPPフォルダーに分離されています。
srcか、それともフロントエンドアプリが独自のフォルダー（独自のpackage.jsonフォルダー構造を持つ）を取得しますか？
これは、フォルダ構造自体に関する間接的な回答であり、非常に関連しています。
数年前、私は同じ質問をし、フォルダー構造を取りましたが、フォルダーはインターネットで読んだのとは異なる目的、つまり特定のフォルダーの機能とは異なる目的のために作成されたため、後で多くのディレクトリを移動する必要がありました一部のフォルダでは、人によって意味が異なります。
ここで、他のすべての回答の説明に加えて、フォルダー構造自体について複数のプロジェクトを実行したので、Node.js自体の構造に従うことを強くお勧めします。これは、https：//github.com/で確認できます。 nodejs / node。それは、リンターや他の人たちが言うように、彼らが持っているファイルとフォルダーの構造と場所について、非常に詳細に書かれています。一部のフォルダーには、そのフォルダーの内容を説明するREADMEがあります。
上記の構造から始めるのは良いことです。いつか新しい要件が発生しますが、現在は何年にもわたって維持されているNode.js自体がすでに続いているため、改善の余地があります。
お役に立てれば。
何が最善のアプローチであるかについてのコンセンサスはなく、一般に関連するフレームワークは特定の構造を強制したり報酬を与えたりしないことに注意することが重要です。
これは苛立たしく、大きなオーバーヘッドであることがわかりますが、同様に重要です。これは、スタイルガイドの問題の軽視されたバージョンです（ただしIMOの方が重要です）。答えは同じなので、私はこれを指摘しておきます。明確に定義され、首尾一貫している限り、どの構造を使用してもかまいません。
だから私はあなたが好きな包括的なガイドを探すことを提案し、プロジェクトがこれに基づいていることを明確にします。
これに慣れていない場合は特に、簡単ではありません。調査に何時間も費やすことを期待してください。MVCのような構造を推奨するほとんどのガイドが見つかります。数年前はそれが堅実な選択だったかもしれませんが、今日では必ずしもそうではありません。たとえば、ここに別のアプローチがあります。
WebアプリケーションとAPIの構築について話していると仮定します。
1つのアプローチは、マイクロサービスアーキテクチャのように、ファイルを機能別に分類することです。私の意見の最大の勝利は、どのファイルがアプリケーションの機能に関連しているかを確認するのが非常に簡単であるということです。
説明する最良の方法は、例を使用することです。
ライブラリアプリケーションを開発しています。アプリケーションの最初のバージョンでは、ユーザーは次のことができます。
2番目のバージョンでは、ユーザーは次のこともできます。
3番目のバージョンでは、ユーザーは次のこともできます。
まず、次の構造があります。
books
├─ controllers
│ ├─ booksController.js
│ └─ authorsController.js
│
└─ entities
├─ book.js
└─ author.js次に、ユーザーとローンの機能を追加します。
user
├─ controllers
│ └─ userController.js
├─ entities
│ └─ user.js
└─ middleware
└─ authentication.js
loan
├─ controllers
│ └─ loanController.js
└─ entities
└─ loan.jsそして、お気に入りの機能：
favorites
├─ controllers
│ └─ favoritesController.js
└─ entities
└─ favorite.js追加するタスクを渡された新しい開発者が、お気に入りとしてマークされている書籍があれば、ブック検索でも情報を返す必要があるため、コード内のどこを見るべきかを簡単に確認できます。
その後、製品の所有者が一掃して、お気に入りの機能を完全に削除する必要があることを宣言すると、簡単に削除できます。