Another works Developers Blog

<h2>はじめに</h2>
<p>こんにちは。nonoyamalfoyです。<br>
弊社ではwebをnext.js, アプリをreact-nativeで開発しています。<br>
フロントエンドアーキテクチャので最近流行りのfeaturesアーキテクチャについての見解を述べようと思います。</p>
<h2>featuresとは</h2>
<p>超簡単にいうと、機能ごとにUIやロジックを隠蔽していくディレクトリ構造。</p>
<pre><code class="language-jsx">features
   ├── message（メッセージ機能）
   │    ├── hooks/
   │    ├── types/
   │    └──  ui
   │         ├── origin/
   │         └── pages/
   ├── profile/（プロフィール機能）
   └── signin/（サインイン機能）
</code></pre>
<h2>React公式の見解</h2>
<p>React は、ファイルをフォルダーに入れる方法について意見を持っていませんが、以下の２つを例として上げています。</p>
<ul>
<li>機能またはルートによるグループ化<br>
「機能」の定義は普遍的なものではなく、粒度を選択するのはユーザー次第とのこと。<br>
featuresなどはこちらに分類されます。</li>
</ul>
<pre><code class="language-ts">message/
    index.ts
    messageApi.ts
    message.tsx
    message.css
    message.story.tsx
    message.test.ts
profile/
    index.ts
    profileApi.ts
    profile.tsx
    profile.css
    profile.story.tsx
    profile.test.ts
</code></pre>
<ul>
<li>同様のファイルをグループ化<br>
Atomicデザインなどはこちらに分類される。</li>
</ul>
<pre><code class="language-ts">api/
    messageApi.ts
    profileApi.ts
components/
    profile.tsx
    profile.css
    profile.story.tsx
    profile.test.ts
    message.tsx
    message.css
    message.story.tsx
    message.test.ts
</code></pre>
<p><a href="https://reactjs.org/docs/faq-structure.html">File Structure - React</a></p>
<h2>複業クラウドの例</h2>
<h3>初期の頃の構成</h3>
<p>リリース初期は同様のファイルをグループ化する形をとっていました。</p>
<ul>
<li>componentsやhooksの肥大化が発生。</li>
<li>componentsディレクトリに切り分けたコンポーネントを入れていくので、抽象的な名前をつけてしまうと名前が被ることがあり後々後悔することになる。</li>
<li>該当のコンポーネントがどこにあるのか、どこで使われているのかがわかりにくい</li>
</ul>
<pre><code class="language-jsx">src
├── components（ドメインロジックのない汎用的なコンポーネント）
│      ├── atoms/（最小の粒度、TextAtom, IconAtomなど）
│      ├── molecules/（atomの集合体、基本的に複数箇所で利用される）
│      └── organisms/（atom,moleculesの集合体、複数箇所で利用されない場合もある）
├── windows
│      ├── components/（ドメインロジックのあるコンポーネント、ページの肥大化、コンポーネントの共通化を目的に切り分けたものを格納）
│      ├── member/
│      ├── public/
│      └── route/(ルーティング)
├── lib/
├── models/
├── modules/(サーバーとの接続)
└── hooks/
</code></pre>
<h3>2023年1月現在</h3>
<p>features内でhooksやuiを分けることで機能ごとの依存を防ぐようにしました。</p>
<pre><code class="language-jsx">src
├── features
│      ├── message（メッセージ機能）
│      │           ├── hooks/
│ 	  │           ├── types/
│      │           └──  ui
│      │                 ├── origin/
│      │                 └── pages/
│      ├── profile/（プロフィール機能）
│      └── signin/（サインイン機能）
├── ui
│    ├── origin
│    └── homeland
├── adapter/(サーバーとの接続,apiを叩いてデータを返す)
└── lib/(汎用的なロジック)
</code></pre>
<h2>featuresアーキテクチャの特徴</h2>
<ul>
<li>機能単位ごとに疎結合にできる（これが一番大きいメリットだと感じています。）
<ul>
<li>機能単位で改善することが多いので不要なデグレを避けることができる</li>
<li>機能削除する際にディレクトリごと消せばいい</li>
</ul>
</li>
<li>featuresディレクトリを見ると、プロダクトにどんな機能が存在するのかわかる</li>
<li>機能を意識した実装や見積もりを行うことができる
<ul>
<li>機能によってはUIから作成したい場合、ロジックから作成したい場合、型から実装したい場合などいろいろなケースがあるかと思います。</li>
</ul>
</li>
<li>コンポーネントの命名に迷うことが減る。</li>
<li>ドメインを意識した開発を行える。</li>
</ul>
<p>下記でもう少し詳しく解説します。</p>
<h2>機能単位ごとに疎結合にできる</h2>
<p>プロダクト開発は機能単位で改善、削除することが多いです。<br>
そのため、他のfeatures同士で依存しないよう意識すれば編集を入れても他の機能への影響が出にくくなります。<br>
また、機能削除する際にディレクトリごと消せばいいので楽になります。</p>
<h2>プロダクトにどんな機能が存在するのかすぐにわかる</h2>
<p>以下のようにfeaturesを見ればmessege, profile, signinの機能があることがすぐにわかります</p>
<pre><code class="language-jsx">features
   ├── message（メッセージ機能）
   │    ├── hooks/
   │    ├── types/
   │    └──  ui
   │         ├── origin/
   │         └── pages/
   ├── profile/（プロフィール機能）
   └── signin/（サインイン機能）
</code></pre>
<h2>ドメインを意識した開発がしやすい</h2>
<p>featuresアーキテクチャでは機能ごとにUIとロジックを隠蔽できるため、ロジックから作成する。型から作成する。といった機能に焦点を当てた開発がとてもしやすいメリットがあります。</p>
<h2>コンポーネントの命名に迷うことが減る。</h2>
<p>機能ごとにファイルを隠蔽できるため、別の機能とコンポーネント名がかぶっても問題がない。<br>
例えば機能やページごとに異なる「Header」が存在した場合、「~Header」みたいにする必要はなく「Header」という名前で実装できる。</p>
<h3>Tips</h3>
<p>feature同士の依存を強制的に防ぐために、eslintを利用できます。</p>
<pre><code class="language-json">rules: {
    'import/no-restricted-paths': [
      'error',
      {
        zones: [
	//profile feature以外でtargetのpathをインポートできないように
          {
            from: './src/features/!(profile)/**/*', // 対象の依存パス 
            target: './src/features/profile', // 禁止するパス
            message: 'features同士で依存することはできません',// エラーメッセージ
          },
	 //message feature以外でtargetのpathをインポートできないように
          {
            from: './src/features/!(message)/**/*', // 対象の依存パス
            target: './src/features/message', // 禁止するパス
            message: 'features同士で依存することはできません', // エラーメッセージ
          },
        ],
      },
    ],
  },
</code></pre>
<h2>最後に</h2>
<p>featuresアーキテクチャのメリットをいくつか紹介しましたが、機能の少ないプロダクトやリリース初期のプロダクトは「同様のファイルをグループ化」するほうがいいと思っています。<br>
機能が少ない場合はむしろfeaturesの肥大化が起きたり、どの粒度の機能で切るのか悩む時間が発生します。<br>
機能が増えてディレクトリが肥大化してきたタイミングでfeaturesアーキテクチャの導入を検討するのがいいと思います。</p>
<p>「弊社プロダクトの設計をもっと知りたい！」と思った方は以下を合わせてお読みいただけると幸いです。<br>
<a href="https://tech.anotherworks.co.jp/article/frontend-architecture-for-react">複業クラウドのフロントエンド設計</a></p>
<h2>参考文献</h2>
<p><a href="https://dev.to/profydev/screaming-architecture-evolution-of-a-react-folder-structure-4g25#discussion-of-the-featuredriven-folder-structure">Screaming Architecture - Evolution of a React folder structure</a></p>
<p><a href="https://zenn.dev/meijin/articles/bulletproof-react-is-best-architecture">Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件</a></p>
<p><a href="https://zenn.dev/yodaka/articles/eca2d4bf552aeb">Next.jsディレクトリ構成・設計再考（featuresが何を解決するか）</a></p>
<p><a href="https://ja.reactjs.org/docs/faq-structure.html">ファイル構成 - React</a></p>


#Frontend

Reactのディレクトリ構成にfeaturesを導入してみた