nikkie-ftnextの日記

イベントレポートや読書メモを発信

読書ログ | #ちょうぜつ本 第1章 〜クリーンアーキテクチャってそういうことか!〜

はじめに

変更しやすいコードが書けないのにソフトウェア開発とか舐めているのですか1
ごめんなさい〜、nikkieです

アニメも大好きな私。作品選びの軸は「かわいさ」です。
そんな譲れないポイント「かわいい」と技術書がまさかの合体をしたら、控えめに言って最高!
そんな本が存在するんです(なんて僥倖!)
その名もちょうぜつ本(『ちょうぜつソフトウェア設計入門』)!

目次

ちょうぜつ本との出会い

『ちょうぜつソフトウェア設計入門』、副題は「PHPで理解するオブジェクト指向の活用」。

いわゆる「オブジェクト指向」と呼ばれる考え方から発展した分野は,どのようにソフトウェア設計の役に立つのかを,よく知られた原則,テスト駆動開発デザインパターンなどを通じて理解できる一冊です。

読むきっかけの一つはいわしまんさんの書評ブログでした。

おれは今この本の凄さをほんのちょっぴりだが体験した

おれは可愛い女の子キャラがわちゃわちゃするゆるいIT漫画を読んでいたと思ったら いつのまにかクリーンアーキテクチャを完全に理解していた…

これはマジでした(N=2)

ちょうぜつ本とクリーンアーキテクチャ完全理解大作戦

「本書の読み方」によると、第1章 クリーンアーキテクチャ

ソフトウェアの全体的な設計イメージをつかむのが目的です。
どうやってそんなものを作るかという課題には、まだ踏み込みません。(Kindle版 p.30)

そして、私の場合、この目的は見事に達成されました!

きれいな設計とは

きれい=クリーンとは、

他の構造部分に期待されない影響が及ぶ可能性を最少化した設計=デザインがなされた状態です。(Kindle版 p.51)

きれいな設計について、3つの観点が導入されます。

  • 凝集度
  • 依存
  • 安定度

このうち、安定度(=コードの変わりにくさ)がクリーンアーキテクチャの提案と理解しました(安定度以外はクリーンアーキテクチャ以前にもある考え)。

できるだけ変更頻度の高い事情に依存しない (Kindle版 p.52)

変更頻度の高い事情=不安定、ということですね。

安定度は、人間の視点で本質か/本質でないかで予測できるそうです。
本質とは(アプリケーションで解決したい)ユーザの問題です。
たしかに、本質は変えづらそう(ソフトウェアの存在目的にも関わりますからね)。
本質でない技術的な詳細は、本質に比べたらまだ変えやすいかなと感じます。

クリーンアーキテクチャとは

Uncle Bobが4つの円の図で示すクリーンアーキテクチャ
4つの円それぞれがどんなものかの説明は非常にわかりやすく感じました。
この説明を読んで、ようやく、完全理解感が得られました(※いますぐ実装に挑戦したら即鼻っ柱をへし折られそうなので、引き続き読み進めます)

  • ドメインモデル
    • どメイン(円の真ん中にある)、これ好き
    • ユーザーの希望で変わるものを排除し、何を望まれても共通したものを残す (p.53)

    • 現実世界の表現であり、変わらないもの
  • ユースケース
    • 本質から排除された、ユーザーが行いたい操作を表現するロジック (p.54)

    • (内側の円の)ドメインモデルにのみ依存
    • ここまでではアプリケーションとしては実機能を持たない
      • ここまでの関心は現実世界に向く
  • インターフェースアダプター(コントローラーなど)
    • 3層目の関心はコンピューターシステムと付きあうためのモデルづくり

    • 関心はコンピュータシステムに向く
    • (内側の円の)ユースケースを参照する
  • インフラストラクチャ
    • 外部とのやりとりをする技術

    • アプリケーション外部の事情に影響される=不安定
      • 不安定さに対処するため、小分けにする

クリーンアーキテクチャでは、最も外側の円が、アプリケーションの実動作のすべてを担います。(p.58)

ですが、内側にある3つの円がいらないわけではなく、他の構造部分に期待されない影響が及ぶ可能性を最少化するために必要という理解です。

3つの円は不安定なものを安定なものに依存させています!
内側にドメインモデルやユースケースを置くという構造(アーキテクチャ)は、アプリケーションの動作には貢献しないのですが、開発者の生産性のために必要なのです!
このあたり、1章の内容が全部つながって、知的な感動がありました。

クリーンアーキテクチャアーキテクチャのパターン

「共通コンセプト」や「ガイドライン」という語でも説明されました。

アプリケーションを適用して解きたいユーザの課題は固有で、だから独自のソフトウェアが必要という説明はなるほどと思いました。
独自のソフトウェアのアーキテクチャについて拠り所を示したのが、クリーンアーキテクチャという理解です。

つまり考え方であって、具体的な答えを示してくれるものではないのですね。

具体的にこれがそうだと言える決まったかたちがある方法論ではありません。(p.60)

終わりに

ついに言えるぞ


クリーンアーキテクチャ完全に理解した!

実装例を見たり素振りしたり2、またUncle Bobの『Clean Architecture』に挑戦したりしていたのですが、ちょうぜつ本 1章を通してかなり解像度が上がりました。
『Clean Architecture』に再挑戦したい気持ちにもなりましたし、手近なところではUncle Bobによるブログを読んでみてもいいかもと思います。

自分で実装できるかを考えた場合、1章だけでは肝心なポイントがまだ分かっていません。

クリーンアーキテクチャに欠かせない特有の要素、本当に訴えたいことの核心は、プログラミングテクニックを使った、この依存方向の自由な制御です。(Kindle版 p.59)

これって依存性の注入ってやつなのかなとも思うのですが、それを使いこなせるようになるのを楽しみにしてちょっとずつ読んで・素振りしていこうと思います。

実装できるかはこれからですが、クリーンアーキテクチャの4つの円が表すものについて非常に明瞭な解説だったので、ドメインモデルやユースケースという概念を掴みたい方にはオススメです。
ありがとう、ちょうぜつ本(そして、しばらくよろしくお願いします)


  1. 元ネタはお隣の天使様です。天使様はかわいいので好きです(突然の告白)。今回の記事の見出しは1巻からオマージュしています
  2. 『Clean Architectures in Python』を写経しました(1st Edition, Part 2 - Chapter 2) - nikkie-ftnextの日記