<p>自分がフロントエンドのアーキテクチャを考える時に、特に意識していることについてまとめてみました。<br>
改善するべき点が多いと思っていますが、自分の考えを整理する意味で書き残したいと思います。</p>
<h1 id="%E3%81%93%E3%81%93%E3%81%A7%E8%A8%80%E3%81%86%E3%80%8C%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F">
<a class="header-anchor-link" href="#%E3%81%93%E3%81%93%E3%81%A7%E8%A8%80%E3%81%86%E3%80%8C%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F" aria-hidden="true"></a> ここで言う「アーキテクチャ」とは？</h1>
<p>この記事では、アーキテクチャについて主に<strong>コード間の依存関係</strong>の観点で考えています。<br>
「なぜ依存関係なのか」については、次の<a href="#%E6%84%8F%E8%AD%98%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88">意識しているポイント</a>で触れていきます。</p>
<h1 id="%E6%84%8F%E8%AD%98%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88">
<a class="header-anchor-link" href="#%E6%84%8F%E8%AD%98%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88" aria-hidden="true"></a> 意識しているポイント</h1>
<h2 id="%E6%8D%A8%E3%81%A6%E3%82%84%E3%81%99%E3%81%8F%E3%81%99%E3%82%8B">
<a class="header-anchor-link" href="#%E6%8D%A8%E3%81%A6%E3%82%84%E3%81%99%E3%81%8F%E3%81%99%E3%82%8B" aria-hidden="true"></a> 捨てやすくする</h2>
<ul>
<li>書いたコードを捨てやすいようなアーキテクチャを目指したいと思っています。
<ul>
<li>なぜなら、最初から良い設計はできないからです。（まれにできる人もいますが、少なくとも自分はできないです）</li>
<li>開発を重ねて理解が深まることで、より良い設計が見つかります。</li>
<li>良い設計が見つかった時に、既存のコードの修正・削除が必要になりますが、それができないと実現（実装）できないことになってしまいます。</li>
<li>コードが捨てやすければ、容易に書き直しができます。</li>
</ul>
</li>
<li>捨てやすくするには、コード修正時の影響範囲の最小化・把握が大切だと思っています。
<ul>
<li>影響範囲にダイレクトに効いてくるのは<strong>コード間の依存関係</strong>です。</li>
</ul>
</li>
</ul>
<h2 id="%E4%BE%9D%E5%AD%98%E3%81%AF%E5%8D%98%E4%B8%80%E6%96%B9%E5%90%91%E3%81%AB%E3%81%AA%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B">
<a class="header-anchor-link" href="#%E4%BE%9D%E5%AD%98%E3%81%AF%E5%8D%98%E4%B8%80%E6%96%B9%E5%90%91%E3%81%AB%E3%81%AA%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B" aria-hidden="true"></a> 依存は単一方向になるようにする</h2>
<ul>
<li>依存を単一方向に保つことで、コード修正の影響範囲を小さく保つことができます。
<ul>
<li>その結果、影響範囲を容易に把握できるようになります。<strong>コードの変更に強くなります。</strong>
</li>
</ul>
</li>
</ul>
<h2 id="%E5%A4%96%E9%83%A8-api-%E3%81%AB%E4%BE%9D%E5%AD%98%E3%81%99%E3%82%8B%E3%83%AC%E3%82%A4%E3%83%A4%E3%83%BC%E3%82%92%E5%88%B6%E9%99%90%E3%81%99%E3%82%8B">
<a class="header-anchor-link" href="#%E5%A4%96%E9%83%A8-api-%E3%81%AB%E4%BE%9D%E5%AD%98%E3%81%99%E3%82%8B%E3%83%AC%E3%82%A4%E3%83%A4%E3%83%BC%E3%82%92%E5%88%B6%E9%99%90%E3%81%99%E3%82%8B" aria-hidden="true"></a> 外部 API に依存するレイヤーを制限する</h2>
<ul>
<li>外部 API にアクセスするのは特定箇所のコードだけに制限するようにします。</li>
<li>これにより、API の仕様変更があったとしても、その箇所のコードを修正するだけで済むようになります。
<ul>
<li>外部 API は自分たちでコントロールできない領域なので、ここに強く依存すると意図せぬ大改修が発生しかねないです。</li>
<li>なのでこれ、外部 API に限った話ではないです。「<strong>自分たちでコントロールできないものに依存しすぎるな</strong>」ということが言いたいです。</li>
</ul>
</li>
</ul>
<h1 id="%E2%86%91-%E3%82%92%E6%84%8F%E8%AD%98%E3%81%97%E3%81%A6%E8%80%83%E3%81%88%E3%81%9F%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E4%BE%8B">
<a class="header-anchor-link" href="#%E2%86%91-%E3%82%92%E6%84%8F%E8%AD%98%E3%81%97%E3%81%A6%E8%80%83%E3%81%88%E3%81%9F%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E4%BE%8B" aria-hidden="true"></a> ↑ を意識して考えたアーキテクチャ例</h1>
<p>いくつかのレイヤーに分けています。<br>
レイヤー間の依存関係にはルールがあります。</p>
<p><img src="https://res.cloudinary.com/zenn/image/fetch/s--_ee3tNmX--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://storage.googleapis.com/zenn-user-upload/deployed-images/6c34db01f38b53506a2055f7.png%3Fsha%3D6d8148387f093544380b87dc48a66770b921706c" alt="アーキテクチャ例" loading="lazy" class="md-img"></p>
<h2 id="ui">
<a class="header-anchor-link" href="#ui" aria-hidden="true"></a> UI</h2>
<ul>
<li>所謂 View です。</li>
<li>画面を表示する責務を持ちます。</li>
</ul>
<h2 id="application-config">
<a class="header-anchor-link" href="#application-config" aria-hidden="true"></a> Application Config</h2>
<ul>
<li>アプリケーションやフレームワークの設定情報に責務を持ちます。</li>
<li>例えば、Nuxt.js や Next.js の設定などです。</li>
<li>UI 以外に依存します。また、Business Logic には依存しないことが望ましいです。（正直あまり整理できていない...）</li>
</ul>
<h2 id="business-logic">
<a class="header-anchor-link" href="#business-logic" aria-hidden="true"></a> Business Logic</h2>
<ul>
<li>所謂ビジネスロジックに責務を持ちます。</li>
<li>「ビジネスロジック」についてはググってもらえたら色々情報が出てくると思うのでここでは触れません。</li>
<li>UI 以外に依存します。また、Application Config には依存しないことが望ましいです。（ここもあまり整理できていない...）</li>
</ul>
<h2 id="interface-adapters">
<a class="header-anchor-link" href="#interface-adapters" aria-hidden="true"></a> Interface Adapters</h2>
<ul>
<li>外部 API へのアクセスに責務を持ちます。</li>
<li>外部 API へのリクエストを発行したり、取得データを（Entities で定義されたインタフェースに）加工します。</li>
<li>Utilities と Entities に依存します。</li>
<li>また、External API に直接依存はせず、インタフェースを介します。（依存関係の逆転）
<ul>
<li>（理解が正しいかあまり自信がないです...）</li>
</ul>
</li>
</ul>
<h2 id="utilities">
<a class="header-anchor-link" href="#utilities" aria-hidden="true"></a> Utilities</h2>
<ul>
<li>他のどのレイヤーにも所属しない共通ロジックなどの置き場です。</li>
<li>他のどのレイヤーにも依存しないべきです。ただし、Entities は場合によっては可です。</li>
</ul>
<h2 id="entities">
<a class="header-anchor-link" href="#entities" aria-hidden="true"></a> Entities</h2>
<ul>
<li>アプリケーションで扱う対象を定義する責務を持ちます。</li>
<li>エンティティ・ドメインモデルなどと呼ばれているものです。</li>
<li>他のどのレイヤーにも依存してはいけません。</li>
</ul>
<h2 id="external-apis">
<a class="header-anchor-link" href="#external-apis" aria-hidden="true"></a> External APIs</h2>
<ul>
<li>外部 API です。（自分たちで管理していないの外の世界）</li>
</ul>
<h1 id="%E6%94%B9%E5%96%84%E3%81%97%E3%81%9F%E3%81%84%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E7%82%B9">
<a class="header-anchor-link" href="#%E6%94%B9%E5%96%84%E3%81%97%E3%81%9F%E3%81%84%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E7%82%B9" aria-hidden="true"></a> 改善したいと思っている点</h1>
<ul>
<li>Business Logic / Application Config / Interface Adapters が混在しがち
<ul>
<li>複数の責務が 1 つのファイルに混在しがちになる</li>
<li>Nuxt.js を使っていると、store や plugins あたりがカオスになりがち</li>
<li>UI レイヤーにもこれらが潜みがちなので、そうならないような案を考えたい</li>
</ul>
</li>
<li>フレームワークに依存しても良いレイヤーの整理
<ul>
<li>何も意識せずに開発すると、コードのあらゆる箇所で Nuxt.js や Next.js への依存が発生してしまう</li>
</ul>
</li>
<li>定数を定義する場所が曖昧
<ul>
<li>定数を定義する場所が曖昧なので、ルールがほしい</li>
</ul>
</li>
<li>Utilities が割れ窓になりそう
<ul>
<li>比較的何でも置けてしまうので、カオスにならないようなルールがほしい</li>
</ul>
</li>
</ul>
<h1 id="%E5%8F%82%E8%80%83%E3%81%AB%E3%81%97%E3%81%9F%E6%9B%B8%E7%B1%8D%E3%83%BB%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88">
<a class="header-anchor-link" href="#%E5%8F%82%E8%80%83%E3%81%AB%E3%81%97%E3%81%9F%E6%9B%B8%E7%B1%8D%E3%83%BB%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88" aria-hidden="true"></a> 参考にした書籍・ドキュメント</h1>
<ul>
<li><a href="https://www.amazon.co.jp/dp/B07FSBHS2V" target="_blank" rel="nofollow noopener noreferrer">【書籍】Clean Architecture 達人に学ぶソフトウェアの構造と設計</a></li>
<li><a href="https://qiita.com/nrslib/items/a5f902c4defc83bd46b8" target="_blank" rel="nofollow noopener noreferrer">実装クリーンアーキテクチャ - Qiita</a></li>
<li><a href="https://qiita.com/ttiger55/items/50d88e9dbf3039d7ab66" target="_blank" rel="nofollow noopener noreferrer">フロントエンドで Clean Architecture のメリットをテストと共に享受する - React + Jest のサンプル付き - Qiita</a></li>
</ul>


フロントエンドのアーキテクチャを考える時に意識していること

ここで言う「アーキテクチャ」とは？

依存は単一方向になるようにする

外部 API に依存するレイヤーを制限する

↑ を意識して考えたアーキテクチャ例

参考にした書籍・ドキュメント

Discussion