記事の概要

手段(クリーンアーキテクチャ)に囚われて、本来の目的を曖昧にしないため、
クリーンアーキテクチャを導入する際の指針となる目的を備忘録として記事にしています。

クリーンアーキテクチャによる影響

クリーンアーキテクチャが影響を及ぼすのは、アーキテクチャに関する面のみです。
アーキテクチャは開発に制約による規律をもたらします。
つまりアーキテクチャを導入すること自体は、ただの制約であり、開発者の自由度が制限されます。ただし目的はその先の規律にあります。

クリーンアーキテクチャ(規律)がもたらす自由

探し物の低減

物の配置に規律があれば、プロジェクトメンバーが探し物(コード)に使う時間が減ります。
クリーンアーキテクチャでは、主に水平方向にコンポーネントを分離し、機能ごとに適切なコンポーネントに配置するため、コードの配置に規律をもたらします。

シンプルな依存関係

依存関係が複雑なプログラムでは、1つの変更に対する影響の特定が困難になります。
クリーンアーキテクチャでは依存方向を1方向に制限することで、依存関係をシンプルに保ちます。

ハードウェアへの依存の少なさ

早期段階でハードウェアを決定し、それにソフトウェアが依存した作りをしていると、ハードウェアの仕様や、寿命にソフトウェアが左右される状況になります。これではハードウェアへの変更がソフトウェアに与える影響を把握することが難しくなります。
クリーンアーキテクチャではハードウェアへ依存するコードと、ソフトウェアが達成すべきビジネスロジックを明確にレイヤーで区別し、各レイヤーからの外部(ハードウェア)へのアクセスを制限します。
これによりコアなビジネスロジックはハードウェアから保護され、外部の影響を受けずテストや更新を行うことができます

関心ごとの分離

これはクリーンアーキテクチャが分けるレイヤーを表現した図ですが、関心ごととはレイヤーのことを指します。
関心ごとはその時々によって変わりますが、例えば「DBは？UIは？」などの話をする際に、クリーンアーキクチャを導入しているプロジェクトでは、Use Casesの議題が上がることはありません。
その逆で、「顧客データの登録の仕様、削除の仕様」などUse Casesの話をする際に、DBやUIが議題に上がることはなく、話し合いはシンプルになり、レイヤーごとにチームを分けることも可能になります。

おわりに

色々なプロジェクトでクリーンアーキテクチャを導入し始めて4年たちますが、時々受けている恩恵を忘れ、目的を忘れ手段だけが残りそうになる時があります。
制約による規律をもたらす以上、アーキテクトは責任をもって目的を説明できる必要があり、今回は目的の一部を書き出してみました。

クリーンアーキテクチャの参考にした書籍のリンクを張っておきます。