「サードパーティに依存するクラス」と「依存しないクラス」とで分ける理由

はじめに

カルテットの有澤です。先日は認識のズレを共有することのうれしさを投稿させていただきました🙏

以前の記事は OOP研修での物事を記事にしましたが、今回は「Symfony研修」を受けた際に気がついた物事を紹介します🙏

さて、カルテットでは開発者同士の知識の差を減らすために、プロダクトコードのルートディレクトリに、指針とするアーキテクチャが記載されたドキュメントを配置する文化があると、研修の中で知りました。

その内容を読むと 「業務知識を持つクラス」と「サードパーティに依存するクラス」を分けられている ことに気づきました。

本記事では、どんな理由で分けているのか を紹介します😊

「フレームワーク自体に大きな変更があっても、影響を受けてほしくないドメインコードを守ること」 ができます。

Webサービスというものは、長く運用していくとフレームワークのバージョンを上げる機会が出てきます。その際に「実装済の機能を、新しく追加されたコンポーネントに置き換えたい」シーンが出てくるかと思います。

これにより、何も対策をしていなければ、せっかく書いたドメインコードがフレームワークの都合で改修されてしまいます。ドメインコードは業務の知識が詰まっているので、フレームワークの都合で業務の知識が変わるというのは、知識の変化として不自然だと考えています。

なので、このような変化を回避するために、 サードパーティ(外部コンポーネント)に依存しなくする ことで、ドメインコードを守るのが狙いです。

よりわかりやすく伝えるために、以下で図を使いながら説明します。

依存性を分けていない場合の構造の図

上記の図では、Serviceにドメインロジックが含まれているシステムの図です。黄色いボックスは変更があったコンポーネントを指し、赤いボックスは影響を受けるコードです。

図のように、コンポーネントの変更に対し、コンポーネント関連のロジックが影響を受けてしまうのは、やむを得ないと考えますが、ドメインロジックに関しても影響を受けてしまっているのわかります。

これではフレームワークの都合で、ドメインロジックが影響を受けてしまいます。

依存性を分けた場合の構造の図

上記の図では、ドメインロジックを「Model」という層に追い出しています。「Model」は、何に対しても依存していないので、コンポーネントの変更に対しても干渉していないとわかります。

この構造であれば、コンポーネント(サードパーティ)の都合でドメインコードを変更するような事態になりにくいと考えられます。

フレームワークのバージョンの変化に耐えられるように設計することは、今まで深く考えたことがなかったので、研修の中で新しい視点に立つことができました👀

世の中にあるWebサービスというものは、プロダクトに纏わる物事によって寿命は大きく変わりますが、せっかく作るシステムですから、長く運用できる工夫をプログラミングを通して表現していこうと思います😊