普段はフロントエンドエンジニアとしてJavaScript/TypeScript/Aangular/GraphQLを
メインに開発業務を行なっています。
コンポーネント間の依存関係において普段注意していることについてまとめました。まだまだ学び足りない箇所や改善するべき点もありますが、現在の考えを共有したいと思います。もし間違いなどありましたらご指摘いただけると助かります。
エンジニアとして気をつけているコンポーネントの依存関係
コンポーネント設計における依存関係について、具体的にイメージするとこのようになります。
■ View
・ユーザーに表示される画面を表します。
■ Component
・Viewの処理を記載します。
■ Service
・Business Logicをここに記載します。
・業務フロー単位に分けて作成します。
■ Api-Service
・外部のAPIと接続するSereviceです。
■ API
・外部APIのことを指します。
・自分でコントロールすることができないものを指します。
■ DB
・データベースです。
■ Utility
・共通の処理をまとめている場所です。
・各ComponentやServieにおいて使用することが可能です。
依存関係は単一方向にする
コンポーネント間の依存関係は必ず単一方向にして、逆方向に依存させないようにしています。
上記図を例にするとView → Component → Service → APi-Serviceの依存関係があった場合、Service → Componentの方向で依存関係ができてしまうと、コードの影響範囲が拡大してしまうことになります。
例えば、ViewのURLをServiceが取得し処理を分離させたとします。View側で何らかの変更があった時に、Serviceの処理も変更させる必要があり、もし他のエンジニアがそのことを知らなければ、予期せぬバグを生み出してしまうことになります。依存関係を守ることでコード修正の影響範囲の把握が容易になり、保守性が高まります。
ビジネスロジックはできる限りバックエンド側で行う
ジネスロジックを追加する際は、できる限りバックエンドで処理を行うのが望ましいです。どうしてもやむ得ない事情があり、フロントエンドで分岐を追加こともありますが、基本的にバックエンド側で処理を加えるようにしています。
ちなみにServiceでロジックを分けるときは、業務フロー単位で分離させてます。何らかの改修が必要になった場合に、業務フロー毎に改修が容易になるためです。
外部のAPI に依存する処理を制限する
外部のAPI にアクセスするのは特定箇所のコードだけに制限するようにしています。
これは自分たちでコントロールできないものには依存しすぎないという考えに基づきます。たとえAPIの仕様が変更になったとしても、アクセスしている箇所だけ変更すれば良いので、保守性が高まります。
ユーティリティは共通化する
どこにも属すことなく、複数のcomponentで使用するロジックは共通化させて、1箇所にまとめます。オブジェクトやDate整形、ログを取得するユーティリティなどは全て1箇所にまとめて共通で使いまわせるようにします。
所感
コンポーネント設計における依存関係について現在、自身で気をつけていることをまとめてみました。
コンポーネントを適切に分割して、関心毎を混在させないようにしたいですが、まだまだ上手くできていないところも多い（StoreやConfig辺り）ので引き続き学びを深めていきたいと思います。
