Open2

Feature-Sliced Designの調査

とさとさ

Entities層について英文をchatGPTに投げてみた

この説明は、ソフトウェア開発における「エンティティ」(Entities)の概念について述べています。エンティティとは、プロジェクトにおける実世界の概念やビジネスの基本要素を指します。たとえば、ソーシャルネットワークやGitフロントエンドのようなプロジェクトでは、ビジネスが製品を説明する際に使う用語に基づいて、エンティティが定義されます。

この「エンティティ」レイヤーには、静的なUI要素、データストア、およびCRUD(Create、Read、Update、Delete)操作が含まれます。エンティティは、ビジネスの核となる情報を管理し、それらに対する操作を提供します。

以下は、エンティティの例です:

  • ソーシャルネットワークの場合:

    • ユーザー (User)
    • 投稿 (Post)
    • グループ (Group)
  • Gitフロントエンドの場合(例: GitHub):

    • リポジトリ (Repository)
    • ファイル (File)
    • コミット (Commit)

この例では、リポジトリがファイルを含むように、リポジトリはファイルという下位レベルのエンティティを内包する上位エンティティになっています。エンティティの構造がこのように階層的になるのは一般的ですが、上位エンティティを扱う際に、他のレイヤーとの依存関係(インポートルール)を破らずに管理するのは難しいことがあります。

この問題を解決するためのいくつかの提案が示されています:

  1. エンティティのUIには、下位エンティティが挿入されるスロットを用意する
    上位エンティティのUI内に、下位エンティティが動的に挿入される場所(スロット)を確保します。

  2. エンティティ間のビジネスロジックは、ほとんどの場合、"機能(features)"に配置する
    エンティティ同士のビジネスロジック(エンティティ間の相互作用や動作に関するルール)は、エンティティ自身ではなく、アプリケーションの機能層に置くべきです。

  3. データベースエンティティの型定義は、下位レイヤー(Sharedレイヤー)にAPIクライアントの隣に配置する
    データベースに保存されるエンティティの型情報は、共通で使えるように"Sharedレイヤー"に抽出し、APIクライアントなどとともに管理します。

このように、エンティティはソフトウェアの基盤となる概念であり、上手に管理することで、アプリケーション全体の設計がより整理され、効率的になります。

とさとさ
  • 同じレイヤーの別のsegmentに依存しないようにする