Open2
【アーキテクチャ】プロジェクト/ディレクトリ構造の設計について📝 ex) servicesとlogicsの違いと使い分け方について📝
まさぴょん🐱servicesとlogicsの違い
-
Services（サービス層）：
- データベースやAPIなどの外部リソースとの通信を担当
- データアクセス層としての役割
- 例：データベースのCRUD操作、外部APIとの連携
- 現在の実装では、ユーザーの登録・ログイン・更新などのデータアクセス処理を担当
-
Logics（ロジック層）：
- 複雑なビジネスルールや計算を実装
- サービス層から取得したデータに対する加工や処理
- 例：特許データの分析、アルゴリズム処理、複雑な条件判定
- 現在はまだ実装されておらず、
.gitkeepだけがある状態
使い分け方
-
Services: データの永続化や取得に関する処理を担当
- 例：ユーザー情報のCRUD、データベースクエリの実行
-
Logics: 複雑なビジネスロジックやドメインルールを担当
- 例：特許クリアランス調査の解析アルゴリズム、特許データの類似度計算
まさぴょん🐱プロジェクト/ディレクトリ構造の設計について📝
プロジェクト/ディレクトリ構造
cd src
tree -L 1
.
├── apis # APIルート・エンドポイントの定義
├── index.ts # エントリーポイント
├── libs # 共通ライブラリやユーティリティ関数
├── logics # ビジネスロジックの実装
├── services # データアクセスや外部サービスとの連携
├── validations # リクエストのバリデーション
└── vendors # 外部ライブラリの拡張や統合
7 directories, 1 file
System Serveの設計について📝
Serverの設計は、主に「レイヤードアーキテクチャ」に分類されます。
以下の特徴が見られます：
-
明確な責任分離：
- API層（apis）
- サービス層（services）
- ビジネスロジック層（logics）
- データアクセス層（servicesに含まれる）
-
依存方向の一貫性：上位層が下位層に依存する構造
- APIs → Services → Logics
また、部分的に以下の要素も取り入れています：
- クリーンアーキテクチャの影響：ビジネスロジックを中心に据え、外部依存（データベースなど）を分離する考え方
- RESTfulなAPI設計：HonoフレームワークによるHTTPメソッドベースのルーティング
このレイヤードアーキテクチャは、関心事の分離が明確で保守性が高く、中小規模のアプリケーションに適しています。
ただし、完全なドメイン駆動設計（DDD）やCQRS（コマンドクエリ責任分離）のようなより複雑なパターンは採用されていないようです。
他に必要なディレクトリについて📝
現在の構造は基本的にはよく設計されていますが、プロジェクトの拡大に応じて以下のディレクトリを検討することもできます：
- models/: データモデルやインターフェイスの定義
- middlewares/: 認証や権限チェックなどの共通ミドルウェア
- config/: アプリケーション設定の管理
- utils/: libsとは別の小さなユーティリティ関数
- tests/: テストケースを格納するディレクトリ
- migrations/: データベースマイグレーションスクリプト
- constants/: アプリケーション全体で使用する定数
これらは必要に応じて追加することをお勧めします。特に認証機能や複雑なテストが必要になった場合、middlewaresやtestsディレクトリは有用です。