ddd:software-architecture

ソフトウェアアーキテクチャ開発スキル

このスキルでは、品質を重視したソフトウェア開発とアーキテクチャに関するガイダンスを提供します。クリーンアーキテクチャとドメイン駆動設計の原則に基づいています。

コードスタイルのルール

一般原則

• 早期リターンパターン：可読性を高めるため、ネストした条件分岐よりも、可能な限り早期リターンを使用してください
• 再利用可能な関数やモジュールを作成して、コードの重複を避けてください
• 長い（コードが80行を超える）コンポーネントや関数は、複数の小さなコンポーネントや関数に分割してください。他の場所で使用できない場合は、同じファイル内に置いてください。ただし、ファイルのコードが200行を超える場合は、複数のファイルに分割してください。
• 可能な場合は、関数宣言ではなくアロー関数を使用してください

ベストプラクティス

ライブラリ優先のアプローチ

• カスタムコードを書く前に、必ず既存のソリューションを探してください
  • 問題を解決する既存のライブラリがないか npm で確認してください
  • 既存のサービスや SaaS ソリューションを評価してください
  • 一般的な機能にはサードパーティ API の利用を検討してください
• 独自のユーティリティやヘルパーを作成するのではなく、ライブラリを使用してください。たとえば、独自のリトライロジックを書くのではなく、cockatielを使用してください。
• カスタムコードの作成が正当化される場合：
  • ドメイン固有のビジネスロジック
  • 特別な要件があるパフォーマンス重視の処理
  • 外部依存関係の導入が過剰になる場合
  • 完全な制御が必要なセキュリティ上重要なコード
  • 十分に評価しても既存のソリューションが要件を満たさない場合

アーキテクチャと設計

• クリーンアーキテクチャと DDD の原則：
  • ドメイン駆動設計とユビキタス言語に従ってください
  • ドメインエンティティとインフラストラクチャ上の関心事を分離してください
  • ビジネスロジックをフレームワークから独立させてください
  • ユースケースを明確に定義し、分離してください
• 命名規則：
  • 汎用的な名前（utils、helpers、common、shared）は避けてください
  • ドメイン固有の名前（OrderCalculator、UserAuthenticator、InvoiceGenerator）を使用してください
  • 境界づけられたコンテキストの命名パターンに従ってください
  • 各モジュールには、明確で単一の目的を持たせてください
• 関心事の分離：
  • ビジネスロジックと UI コンポーネントを混在させないでください
  • データベースクエリをコントローラーに含めないでください
  • コンテキスト間の境界を明確に保ってください
  • 責務を適切に分離してください

避けるべきアンチパターン

• NIH（ここで発明されていない）症候群：
  • Auth0／Supabase がある場合に、独自の認証機能を構築しないでください
  • Redux／Zustand を使わず、独自の状態管理を実装しないでください
  • 実績のあるライブラリを使わず、独自のフォーム検証機能を作成しないでください
• 不適切なアーキテクチャ上の選択：
  • ビジネスロジックと UI コンポーネントを混在させる
  • コントローラー内にデータベースクエリを直接記述する
  • 関心事の分離が不明確である
• 汎用的な命名に関するアンチパターン：
  • 関連のない関数が50個入ったutils.js
  • 雑多なコードの置き場となったhelpers/misc.js
  • 目的が不明確なcommon/shared.js
• 覚えておいてください。カスタムコードは一行ごとに、保守、テスト、ドキュメント作成が必要な負債になります。

コード品質

• 型付きの catch ブロックを使用して適切にエラーを処理してください
• 複雑なロジックを小さく再利用可能な関数に分解してください
• 深いネスト（最大3段階）を避けてください
• 可能な限り、関数の目的を絞り、50行未満にしてください
• 可能な限り、ファイルの目的を絞り、コードを200行未満にしてください