nextjs clean architecture

next.jsのクリーンアーキテクチャ

このレポは、next.jsでクリーンなアーキテクチャを実現する方法の例です。このプロジェクトを通過するビデオチュートリアルがあります。画像をクリックしてYouTubeでチェックアウトします。

npm installとnpm run dev実行するだけで、プロジェクトを実行できます。

クリーンアーキテクチャ

注記

？私は、オリジナルのクリーンアーキテクチャ図のこの単純化されたバージョンを描きました。私にとってより理にかなっている方法でそれを簡素化し、理解しやすいです。それがあなたにも役立つことを願っています。

クリーンアーキテクチャについて初めて聞いたことがある場合は、ボブおじさんによるオリジナルの記事を読むことを強くお勧めしますが、以下でそれを要約しようとします。

Clean Architectureは、維持とテストが容易であり、コードベースが予測可能であるようにアプリケーションを構築するのに役立つ一連のルールです。これは、開発者が技術的な背景やプログラミング言語の好みに関係なく、一般的な言語のようなものです。

クリーンアーキテクチャ、および同様の/派生アーキテクチャには、すべて同じ目標があります -懸念の分離。同様のコードを一緒にバンドルするレイヤーを導入します。 「レイヤー化」は、コードベースで重要な側面を達成するのに役立ちます。

• UIとは独立している- ビジネスロジックは、使用されているUIフレームワークと結合されていません（この場合は次の.js）。同じシステムを、ビジネスロジックやルールを変更することなく、CLIアプリケーションで使用できます。
• データベースとは無関係- データベースの実装/操作は独自のレイヤーで分離されているため、アプリの残りの部分はどのデータベースが使用されているかを気にしませんが、モデルを使用して通信します。
• フレームワークとは独立している- ビジネスルールとロジックは、外の世界について何も知らないだけです。プレーンJavaScriptで定義されたデータを受け取り、プレーンJavaScript、サービス、リポジトリを使用して、独自のロジックと機能を定義します。これにより、システムを実装や制限に「形成」する代わりに、フレームワークをツールとして使用できます。アプリでルートハンドラーを使用し、それらの一部をサーバーアクションにリファクタリングする場合、ルートハンドラーの代わりにサーバーアクションで特定のコントローラーを呼び出すだけですが、コアビジネスロジックは変更されていません。
• テスト可能- ビジネスロジックとルールは、UIフレームワーク、データベース、Webサーバー、またはシステムを構築するその他の外部要素に依存しないため、簡単にテストできます。

クリーンアーキテクチャは、依存関係の階層を定義することでこれを達成します - レイヤーはその下のレイヤーのみに依存しますが、上ではありません。

プロジェクト構造（重要なビットのみ）

• app -フレームワークとドライバーレイヤー- 基本的にすべてのnext.js（ページ、サーバーアクション、コンポーネント、スタイルなど...）またはアプリのロジックを「消費」するもの
• di依存関係インジェクション - DIコンテナとモジュールをセットアップするフォルダー
• drizzle -EverythingDB- DBクライアントの初期化、スキーマ、移行の定義
• srcシステムの「ルート」
  • application -アプリケーションレイヤー- リポジトリとサービスのためのユースケースとインターフェイスを保持します
  • entities -エンティティレイヤー- モデルとカスタムエラーを保持します
  • infrastructure -インフラストラクチャレイヤー- リポジトリとサービスの実装を保持し、 applicationからインターフェイスを引き込みます
  • interface-adapters -インターフェイスアダプターレイヤー- システムへのエントリポイントとして機能するコントローラーを保持します（システムと対話するためにフレームワークとドライバーレイヤーで使用）
• tests - ユニットテストはここに住んでいます - unitサブフォルダーの構造はsrcと一致します
• .eslintrc.json eslint-plugin-boundariesプラグインが定義されている場所 -これにより、依存関係ルールが壊れるのが妨げられます
• vitest.config.ts @エイリアスの定義方法に注意してください！

説明の説明

• Frameworks＆Drivers ：すべてのUIフレームワーク機能、およびシステムと相互作用する他のすべてを保持します（例：aws lambdas、stripe webhooksなど）。このシナリオでは、次のようなものです。JSルートハンドラー、サーバーアクション、コンポーネント（サーバーとクライアント）、ページ、設計システムなど...
  • このレイヤーは、コントローラー、モデル、エラーのみを使用する必要があり、ユースケース、リポジトリ、およびサービスを使用してはなりません。
• インターフェイスアダプター：コントローラーを定義します。
  • コントローラーは、特定のユースケースに入力を渡す前に、認証チェックと入力検証を実行します。
  • コントローラーはユースケースを調整します。ロジックは実装していませんが、ユースケースを使用して操作全体を定義します。
  • より深いレイヤーからのエラーがバブルアップし、コントローラーが使用されている場所で処理されます。
  • コントローラーは、プレゼンターを使用して、データを「消費者」に戻す直前にUIに優しい形式に変換します。これにより、JavaScriptをクライアント（ロジックとライブラリを変換するためにロジックとライブラリ）に出荷することが少なくなり、電子メールやハッシュされたパスワードなどの機密プロパティの漏れを防ぐのに役立ち、クライアントに送り返すデータの量をスリムにするのに役立ちます。
• アプリケーション：ビジネスロジックが生きている場所。 Coreと呼ばれることもあります。このレイヤーは、サービスとリポジトリのユースケースとインターフェイスを定義します。
  • ユースケース：
    • 「Create Todo」や「Signin」や「Toggle Todo」などの個々の操作を表します。
    • 事前検証された入力（コントローラーから）を受け入れ、承認チェックを処理します。
    • リポジトリとサービスを使用して、データソースにアクセスし、外部システムと通信します。
    • ユースケースは他のユースケースを使用しないでください。それはコードの匂いです。これは、ユースケースが複数のことを行うことを意味し、複数のユースケースに分類する必要があります。
  • リポジトリとサービスのインターフェイス：
    • これらは、ツールとフレームワーク（データベースドライバー、電子メールサービスなど）の依存関係を分割したいため、このレイヤーで定義されているため、インフラストラクチャレイヤーに実装します。
    • インターフェイスはこのレイヤーに住んでいるため、ユースケース（およびトランザティブに上層層）は依存噴射を通じてそれらにアクセスできます。
    • 依存関係の噴射により、定義（インターフェイス）を実装（クラス）から分割し、それらを別のレイヤー（インフラストラクチャ）に保持できますが、それでも使用を許可します。
• エンティティ：モデルとエラーが定義されている場合。
  • モデル：
    • 「データベース」テクノロジーを使用せずに、Plain JavaScriptで「ドメイン」データ形状を定義します。
    • モデルは常にデータベースに結び付けられているわけではありません - 電子メールの送信データベースではなく、外部の電子メールサービスが必要ですが、他のレイヤーが「電子メールの送信」を通信するのに役立つデータ形状が必要です。
    • モデルは、「エンタープライズビジネスルール」と呼ばれる独自の検証ルールも定義します。通常は変更されないルール、または外部が変更された場合に変更する可能性が最も低いルール（ページナビゲーション、セキュリティなど）。例は、少なくとも6文字の長さであり、特殊文字を含まない必要があるユーザー名フィールドを定義するUserモデルです。
  • エラー：
    • データベース固有のエラーや、ライブラリまたはフレームワークに固有のあらゆるタイプのエラーを泡立たせたくないため、独自のエラーが必要です。
    • 他のライブラリ（霧雨など）からのエラーcatch 、それらのエラーを自分のエラーに変換します。
    • これが、クリーンアーキテクチャの最も重要な側面の1つである、あらゆるフレームワーク、ライブラリ、テクノロジーからコアを独立させる方法です。
• インフラストラクチャ：リポジトリとサービスが定義されている場合。
  • このレイヤーは、アプリケーションレイヤーからリポジトリとサービスのインターフェイスを引き込み、独自のクラスでそれらを実装します。
  • リポジトリは、データベース操作の実装方法です。これらは、 getTodo 、 createTodo 、 updateTodoなどの単一のデータベース操作を実行するメソッドを公開するクラスです。これは、これらのクラスでのみデータベースライブラリ /ドライバーを使用することを意味します。データの検証を実行せず、データベースに対してクエリと突然変異を実行するだけで、カスタム定義されたエラーをスローするか、結果を返します。
  • サービスは、認証サービス、電子メールサービスなど、アプリケーション全体で使用されている共有サービス、またはStripeなどの外部システムを実装します（支払いの作成、領収書など）。これらのサービスは、他のフレームワークやライブラリも使用し、依存しています。そのため、リポジトリと一緒に実装がここに保持されています。
  • レイヤーがこれに依存したくないため（およびデータベースとすべてのサービスに依存するレイヤー）、依存関係の反転原理を使用します。これにより、インフラストラクチャレイヤーの実装ではなく、アプリケーションレイヤーで定義されたインターフェイスのみに依存できます。 Ioctopusのような制御ライブラリの反転を使用して、インターフェイスの背後にある実装を抽象化し、必要なときにいつでも「注入」します。 diディレクトリに抽象化を作成します。リポジトリ、サービス、コントローラー、およびユースケースをシンボルに「バインド」し、実際の実装が必要なときにそれらのシンボルを使用して「解決」します。これが、明示的に依存する必要なく、実装を使用する方法です（インポート）。

よくある質問

ヒント

FAQでカバーされていない質問がある場合は、このリポジトリで問題を開くか、Discordサーバーに参加して会話を始めてください。

Clean Architecture /この実装はサーバーレスフレンドリーですか？これをVercelに展開できますか？

はい！ページルーター、アプリルーター、ミドルウェア、APIハンドラー、サーバーアクション、本当に何でも使用できます！通常、JavaScriptプロジェクトで依存関係注入を達成することは、inversify.jsライブラリで行われています。これは、ノード以外の他のランタイムと互換性がありません。このプロジェクトは、IoCtopusを実装します。IoCtopusは、 reflect-metadataに依存せず、すべてのrantymentで動作する単純なIOCコンテナです。

Next.jsプロジェクトを作成するときに、すぐにClean Architectureの実装を開始する必要がありますか？

私はノーと言います。新しいプロジェクトを開始している場合は、MVPステータスをできるだけ早く達成することに集中することをお勧めします（そのため、あなたのアイデアを検証する /プロジェクトに未来があるかどうかを確認できます）。物事が深刻になり始めたとき（より多くの機能が実装され始めたとき、ユーザーベースが大幅に成長するか、プロジェクトの他の開発者を搭載している場合）、それはこのアーキテクチャ（または任意のアーキテクチャ）の適応に時間を費やしたいときです。

すでにプロジェクトの雑草に深く深い場合は、次のスプリントから徐々にリファクタリングすることを計画できます。この場合、コードは既に書かれているので、それを少し再編成する必要があります。また、ルートハンドラーごとにルートハンドラー、サーバーアクションによるサーバーアクションによってその部分を実行できます。ちなみに、私はそれを軽く「あなたはそれを少し再編成する必要がある」と言っていますが、それはそれと同じくらい単純であることからはほど遠いことがあります。リファクタリングを計画するときは、常に「間違っている」ことを考慮に入れてください。そして、テストを書くのに時間を費やしてください！

これはエンジニアリングのように見え、機能開発を複雑にします。

これについて考える3分以上を費やさないと、はい、それはエンジニアリングのように見えます。しかし、もしそうなら、あなたはそのアーキテクチャ=規律に気付くでしょう。アーキテクチャは、どこに行くかを定義する開発者間の契約です。コードベースを予測可能にし、それらの決定をあなたのために行うため、機能開発を実際に簡素化します。

それに取り組んでいるすべての開発者が、それが最も便利なコードを書いている場合、プロジェクトを持続可能に成長させることはできません。コードベースは、一緒に働くための悪夢に変わり、それがあなたが本当に複雑な機能開発プロセスを感じるときです。これと戦うために、最終的にはいくつかのルールを置きます。これらのルールは、チームが直面し、新しい問題を解決するにつれて成長します。これらすべてのルールをドキュメントに入れてください。そうすれば、独自のアーキテクチャ定義があります。あなたはまだある種のアーキテクチャを実装していますが、その点に非常にゆっくりと痛みを伴って到達しました。

クリーンアーキテクチャは、テストされたショートカットと事前定義されたアーキテクチャを提供します。そして、はい、確かに、あなたはこれらすべてを学ぶ必要がありますが、あなたはあなたの生涯に一度それをし、そしてあなたが将来使用するあらゆる言語またはフレームワークで原則を適用するだけです。

すべてのプロジェクトにクリーンアーキテクチャを適用する必要がありますか？

いいえ。プロジェクトが成長すると予想していない場合、機能の数、ユーザー数、またはそれに取り組んでいる開発者の数の両方ではそうではありません。

アーキテクチャを清掃するための他の同様のアーキテクチャは何ですか？

私がReadmeの一番上で述べた元のブログ投稿で述べたように、あなたは次のようにしました：

• Alistair Cockburnによる六角形アーキテクチャ（別名ポートとアダプター）
• ジェフリーパレルモによるオニオンアーキテクチャ
• ボブおじさんによる叫びの建築（クリーンアーキテクチャの背後にある同じ男）
• そしてさらにいくつか（元のブログ投稿をチェックしてください）