【Clean Architecture座談会】第1回・第2回

mohikanzというエンジニアコミュニティで、Clean Architectureを読んだ人で集まってオンライン座談会を始めました。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Jambordというホワイトボードアプリを使って、各章を追いながら各自の疑問点や実践事例を共有しています。

第1回と第2回を終え、15章「アーキテクチャとは？」まで進めたので、座談会のグラレコ？を公開していこうと思います。

本の内容と座談会で話されていた内容が特に区別されずに書かれているのは申し訳ないですが、あくまで座談会のグラレコである所に留意いただけますと幸いです。

あとJambordを使って双方向のまとめを試みていたので形式はばらばらです。

第1回

第1回では序章はさっくり飛ばして、プログラミング言語パラダイムの移り変わりとSOLID原則について互いの理解を補完し合いました。

自分はSOLID原則分かっているつもりで、OCPが「保護される対象を見定めて」適用するという発想が全く無かった（全てのクラスを守らないといけないと思ってた、無理）ので、ここでようやく理解ができました。

ただ今見返すとISPとDIPで同じこと書いているように見えるし実際どこに違いがあるのか分かっていません。読み直して補足しよう。

第2回

第2回の大半はコンポーネントについての話でした。

「コンポーネント is 何？」という話を最初に（結構な時間を掛けて）やったのですが、あの議論があったからこそ後半の会話がスムーズにいったと思います。コンポーネントが持つべき3原則を見返しながら、「俺達はWebフレームワーク単位でデプロイしている」「もっと小さな単位が存在するのでは」という話ができました。実際にコンポーネントの区切りを意識して開発している人に話を聞いてみたくなりました。npmパッケージ開発とかかな。

「安定したコンポーネント」という定義も興味深かったです。本の中では複数のコンポーネントから依存されているコンポーネントを「安定したコンポーネント」と呼んでいました。これは「安定させたいコンポーネント」とは異なります。安定させたいものと安定しているものを揃えるために、あの同心円の図があることに今更ながら気付きました。

後半はアーキテクチャについて。以下本文から引用します。

アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである。
それらを容易にするための戦略は、できるだけ長い期間、できるだけ多く選択肢を残すことである。

例えばDBの選定をRDBにするのかNoSQLにするのか後回しにする（Repository層のInterfaceを作って依存しないようにする）。単なる先延ばしではなく、動かしてみないと分からない事を動かしてみて明らかにする、を優先する思想です。

そのようにして判断を先延ばしにできるように組んだアーキテクチャは、後から優れた後発技術が現れた時に差し替えが可能なのではないかという話も上がりました（これは「UNIXという考え方」に載っていた思想でもあります）。

また、そこまで大規模でないソフトウェアで設計をどこまで凝るのか？　という話が上がったのですが、ソフトウェアの寿命は現在の開発者が見積もるより大体常に伸びるものであると同時に、アーキテクトならぬビギナー開発者であれば、既存のソフトウェアの設計を参考に新しいソフトウェアを設計するので、イケてない設計をしたときにはそれが増産される恐れがあるという話もしました。

一方で最初から完璧な設計にはならないし、今後ソフトウェア工学が発展すれば、Clean Architectureより優れた設計思想が生み出される可能性もあります。そのような状況でも唯一不変の原則があるとすれば、アーキテクチャを変更可能に保っておく事なのでしょう。

全体通して

Clean Architectureについての輪読会は1回やったので概ね理解しているつもりだったのですが、全然まだまだでした。

現在新規のプロジェクトをClean Architectureに基づいて実装してみているので、経験を語れるようになっておきたいです。

mohikanzって何よ

mohikanz - Qiita

エンジニアのための雑談コミュニティです。雑談コミュニティと言いつつ、つよつよな人達がヒャッハーしながら技術の話や技術以外の話で盛り上がっている場所です。楽しいよ。