概要

実践ドメイン駆動設計（IDDD）を一応読み終わり、Clean Architectureも流し見程度でもいいから読もうかなと衝動買いしてこちらも読み終わったので気になったところ、気付いたところを書き残してみたい。

部分的に

▼アーキテクチャのルールはどれも同じである！
と序文に書かれている。数十年前から今日まで、レイヤードだのオニオンだのヘキサゴナルだの色々アーキテクチャが生まれたが、条件分岐やループ処理を組み合わせてプログラムを構築すること自体は昔と変わっていない。変わったことといえば色々学びを得てきたおかげで不変（普遍）のルールを知るようになった、そしてそれが本書に書かれている、と堂々とした感じで始まる。

DDDやヘキサゴナルなどのアーキテクチャに強い関心を持つようになった理由として、業務上知識として必要というのもあるが、恐らくそれらは普遍的なものだろうから学んでおきたいと思ったところがあったので、実に興味深い序文でよかった。

▼ソフトウェアアーキテクチャの目的はシステムの構築・保守に必要な人材を最小限に抑えること
アーキテクチャの目的は何なのかと考えたことが無かったが、なるほどなと思った。「構築」に目がいってしまっていたが、バグを生みにくくしたり改修をしやすくしたりと、確かに作るだけでなく運用していく上でとても効果的だと思う。

本では運用崩壊のサインについて、実例でのコード1行あたりのコスト、リリース毎に必要となった予算のグラフが紹介されている。時間が経つにつれ、コードが更新されるにつれ生産性が悪くなり、リリースに必要なコストが右肩上がりに増加し続けていることを示している。

これは実体験としてよく分かることで、リリースサイクルに追われるような開発現場では、クリーンなコードを新しく書くことも、コードをクリーンにする（リファクタリング）ことも出来なくなる。そのクリーンではないことが起因して開発が遅れ、またクリーンにする機会が損失されるという負のループに入る。そうなると既存のクリーンでないコードを手っ取り早く流用する形になり、もはやクリーンかどうかなど気にせずコードを組み上げるだけになってしまう。
さらに、時間に追われ続けることの危険性はコードに現れるだけでなく、チームや会社全体へ影響が出てしまうのではとよく考えてしまう。生産性の高まる技術や考え方を共有する機会が無くなると技術レベルの水準が高まらず、それが続くとやがて改善する意識も持てなくなってしまう。目の前の施策は確かに売上が上がるかもしれないが、1年後チームメンバーがそれぞれ志を持って働けているか軽視せずに考えなくてはいけないと思う。

▼オブジェクト指向(OO）とは
OOとは「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」とある。自分としては「オブジェクト同士が呼び出し合い協調させて凝集度の高いシステムを構築する考え方」と思っていたが、クラスのような概念は目新しいものでも特別なものでもなく、OOで生み出されたものとして特筆すべきはポリモーフィズムと依存関係逆転のパワーということだった。

実際に現場でこれらが使われているプロジェクトでは、コードが整理されていて、何を行おうとしているものなのか、手を加えるならどこを触ればよいのかが分かりやすい印象がある。
例えば、特定の処理を行なっているクラスがあり、その後続処理を追加したい要望があった場合対応は何パターンかありそう。「単純に元クラスに後続処理を追加する」「後続処理を別クラスに抽出して処理を移譲する」「後続処理の振る舞いを抽象化してインターフェースで切り出して処理を移譲する形にし、インスタンスをコンストラクタで依存性の注入を行う」など。
テスト容易性を考えると最後の実装にするとモックで置き換えが出来てよかったりするが、チームの方針やプロジェクト（プロダクト）のフェーズでも変わってくる。

慣れると当たり前のように感じてしまうが色々な箇所での認知負荷の軽減の積み重ねはとても大きい。だからこそPullRequestのレビューも時間を掛けて細かく行われていたりして、短期的な視点で妥協を繰り返さないことが大事と感じる。

あとがき

大分前に読み終わり下書きも途中で放置していたがせっかくなので追記して締めた。新しく取り入れるという点でも、自分の考えの確らしさを確認する点でも、たった数千円で賢人の知恵を拝借できるのはよい投資だと思う。