Help us understand the problem. What is going on with this article?

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

自分がフロントエンドのアーキテクチャを考える時に、特に意識していることについてまとめてみました。
改善するべき点が多いと思っていますが、自分の考えを整理する意味で書き残したいと思います。

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

この記事では、アーキテクチャについて主にコード間の依存関係の観点で考えています。
「なぜ依存関係なのか」については、次の意識しているポイントで触れていきます。

意識しているポイント

捨てやすくする

  • 書いたコードを捨てやすいようなアーキテクチャを目指したいと思っています。
    • なぜなら、最初から良い設計はできないからです。(まれにできる人もいますが、少なくとも自分はできないです)
    • 開発を重ねて理解が深まることで、より良い設計が見つかります。
    • 良い設計が見つかった時に、既存のコードの修正・削除が必要になりますが、それができないと実現(実装)できないことになってしまいます。
    • コードが捨てやすければ、容易に書き直しができます。
  • 捨てやすくするには、コード修正時の影響範囲の最小化・把握が大切だと思っています。
    • 影響範囲にダイレクトに効いてくるのはコード間の依存関係です。

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

  • 依存を単一方向に保つことで、コード修正の影響範囲を小さく保つことができます。
    • その結果、影響範囲を容易に把握できるようになります。コードの変更に強くなります。

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

  • 外部 API にアクセスするのは特定箇所のコードだけに制限するようにします。
  • これにより、API の仕様変更があったとしても、その箇所のコードを修正するだけで済むようになります。
    • 外部 API は自分たちでコントロールできない領域なので、ここに強く依存すると意図せぬ大改修が発生しかねないです。
    • なのでこれ、外部 API に限った話ではないです。「自分たちでコントロールできないものに依存しすぎるな」ということが言いたいです。

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

いくつかのレイヤーに分けています。
レイヤー間の依存関係にはルールがあります。

image.png

UI

  • 所謂 View です。
  • 画面を表示する責務を持ちます。

Application Config

  • アプリケーションやフレームワークの設定情報に責務を持ちます。
  • 例えば、Nuxt.js や Next.js の設定などです。
  • UI 以外に依存します。また、Business Logic には依存しないことが望ましいです。(正直あまり整理できていない...)

Business Logic

  • 所謂ビジネスロジックに責務を持ちます。
  • 「ビジネスロジック」についてはググってもらえたら色々情報が出てくると思うのでここでは触れません。
  • UI 以外に依存します。また、Application Config には依存しないことが望ましいです。(ここもあまり整理できていない...)

Interface Adapters

  • 外部 API へのアクセスに責務を持ちます。
  • 外部 API へのリクエストを発行したり、取得データを(Entities で定義されたインタフェースに)加工します。
  • Utilities と Entities に依存します。
  • また、External API に直接依存はせず、インタフェースを介します。(依存関係の逆転)
    • (理解が正しいかあまり自信がないです...)

Utilities

  • 他のどのレイヤーにも所属しない共通ロジックなどの置き場です。
  • 他のどのレイヤーにも依存しないべきです。ただし、Entities は場合によっては可です。

Entities

  • アプリケーションで扱う対象を定義する責務を持ちます。
  • エンティティ・ドメインモデルなどと呼ばれているものです。
  • 他のどのレイヤーにも依存してはいけません。

External APIs

  • 外部 APIです。(自分たちで管理していないの外の世界)

改善したいと思っている点

  • Business Logic / Application Config / Interface Adapters が混在しがち
    • 複数の責務が1つのファイルに混在しがちになる
    • Nuxt.js を使っていると、store や plugins あたりがカオスになりがち
    • UI レイヤーにもこれらが潜みがちなので、そうならないような案を考えたい
  • フレームワークに依存しても良いレイヤーの整理
    • 何も意識せずに開発すると、コードのあらゆる箇所で Nuxt.js や Next.js への依存が発生してしまう
  • 定数を定義する場所が曖昧
    • 定数を定義する場所が曖昧なので、ルールがほしい
  • Utilities が割れ窓になりそう
    • 比較的何でも置けてしまうので、カオスにならないようなルールがほしい

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

shun91
東京でフロントエンドエンジニアやってます。Nuxt.js + TypeScript で社内アクセス解析ツールをかれこれ2年以上開発しています。
https://github.com/shun91
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした