【翻訳＋意訳・要約】ビジネスコードを他から切り離す

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Keep your business code separate from the rest - DEV Community

意訳+要約

ビジネスコードを他から切り離す

• ビジネスロジックの分離の重要性

  • 古いフレームワークから現代の技術へ移行する際、ビジネスロジックを分離することが重要。
  • 移行の際にビジネスロジックとその他の部分を分けることが難しく、多大な労力を要する。

• コードの持続性

  • 常に「明日異なるフレームワークに移行してもビジネスロジックを持ち運べるか？」を問い続ける。
  • 持ち運べるなら持続性のあるコード。そうでなければリファクタリングが必要。

• 具体的な実践方法

  • ビジネスロジックをbusinessフォルダーに集約。
  • データの読み込みと変更を行う「コントローラー」層を分ける。
  • 外部データやHTTPデータを扱う際はZodスキーマを使用してデータを検証。
  • 検証済みデータをUIコンポーネントにプロップスとして渡す。

まとめ: ブログでは、古いコードベースの現代化を進める際、ビジネスロジックを他のコードから分離することの重要性を強調しています。これにより、将来的なフレームワーク変更時にもビジネスロジックを簡単に移行できるようになります。具体的には、ビジネスロジックを独立したフォルダーに保管し、データ処理層を分けて管理することが推奨されています。

ChatGPTへのQA

Ｑ：フォルダ構成は、どうあるのが最適でしょうか？

最適なフォルダ構成の例:

• src/
  • business/
    • services/
    • models/
    • repositories/
  • controllers/
  • middlewares/
  • routes/
  • utils/
  • config/

詳細:

• business/: ビジネスロジックを集約。サービス、モデル、リポジトリなどを格納。
  • services/: ビジネスロジックを実行するサービス。
  • models/: ビジネスデータモデル。
  • repositories/: データアクセス層。
• controllers/: リクエストを処理し、ビジネスロジックに渡す。
• middlewares/: リクエスト前処理・認証など。
• routes/: APIエンドポイント定義。
• utils/: ヘルパー関数。
• config/: 設定ファイル。

Ｑ：businessフォルダーを分けるのは良いんですが、そこまで破壊的な変更は発生するのでしょうか？

確かにフレームワークが変わる場合、すべてのコードが問題なく移行できる保証はありません。しかし、以下のようにビジネスロジックを分離することで、移行の際の影響を最小限に抑えられる可能性が高まります。

理由

• ビジネスロジックの再利用性: フレームワークに依存しない形でビジネスロジックを記述しておくことで、他のフレームワークに移行する際にも再利用しやすくなります。

• 依存関係の減少: ビジネスロジックとフレームワーク特有のコードを分離することで、特定のフレームワークに強く依存しないコードが作れます。

推奨フォルダ構成

• src/
  • business/:
    • services/: ビジネスロジック（純粋なJavaScript/TypeScriptで書く）
    • models/: データモデル（可能ならPOJO/POCOを使用）
    • repositories/: データアクセス（抽象化レイヤーを使う）
  • controllers/: フレームワーク依存のコントローラー
  • middlewares/: リクエスト処理の前処理
  • routes/: ルーティング定義
  • utils/: ヘルパー関数（フレームワーク非依存）
  • config/: 設定ファイル

移行時のポイント

1. フレームワークに依存しないコード設計: ビジネスロジックをフレームワークに依存しない形で設計する。

2. テストカバレッジの確保: ビジネスロジックに対する単体テストを充実させ、移行後も動作が保証されるようにする。

3. 抽象化レイヤーの活用: データアクセスやサービス呼び出しなどを抽象化し、フレームワークに依存しないインターフェースを設ける。

Ｑ：各フォルダ構成の依存関係について説明お願いします

以下は各フォルダ構成の依存関係についての説明です。

フォルダ構成と依存関係

1. src/

   • アプリケーション全体のルートディレクトリ。

2. business/

   • services/:
     • ビジネスロジックを含む。
     • 他のフォルダ（特にcontrollers）から呼び出される。
     • 基本的にフレームワークに依存しない。
   • models/:
     • ビジネスデータモデルを含む。
     • 他のビジネスロジックやデータアクセス層から利用される。
     • 独立しているが、他のサービスやリポジトリから参照される。
   • repositories/:
     • データアクセスロジックを含む。
     • データベースや外部APIとのやり取りを担当。
     • フレームワークに依存する可能性があるため、抽象化レイヤーを使用する。

3. controllers/

   • リクエストを処理し、適切なビジネスロジックに渡す。
   • ビジネスロジック（business/services）に依存。
   • フレームワークに強く依存。

4. middlewares/

   • リクエストの前処理や認証を行う。
   • ルーティングやコントローラーに依存。
   • フレームワークに依存することが多い。

5. routes/

   • APIエンドポイントを定義。
   • コントローラーに依存。
   • フレームワークに依存。

6. utils/

   • ヘルパー関数を含む。
   • 他のすべてのフォルダから利用可能。
   • フレームワークに依存しない汎用的なコードを含む。

7. config/

   • 設定ファイルを含む。
   • 他のすべてのフォルダから参照される。
   • フレームワークに依存する設定も含まれる。

依存関係の概要

• businessフォルダのコードはフレームワークに依存しないことが推奨されます。
• controllers、middlewares、routesはフレームワークに依存する部分が多いです。
• utilsはどこからでも参照され、フレームワークに依存しません。
• configはアプリケーション全体の設定を含み、すべてのフォルダから参照されます。

このようにフォルダを分けることで、フレームワークの変更時にもビジネスロジックの再利用がしやすくなります。

感想＋雑記

何度かやり取りしたけど、フォルダ構成の正解が分からん。
そもそも、サービスのロジックをどこからするのか、すごく迷うんだけど、俺だけ？
個人開発してるのは、ビジネスロジックがほぼないから、あんまりメリットないので、特に分けることはしてない。
FWが変わることがほぼないので、それなら、フォルダ階層が一貫性あるものがいいと思うんだが。
結局、この構成って、ControllerとServiceが1:1になるから、意味あるのか？って毎回思ってしまう。

未だに納得出来ないんだよな。。。
フォルダ構成で戦争起きてしまいそうな気がする。
たぶん、ガンジーでも戦争起こすと思うね。