cleancodersのJava Case Studyの（私的）UML図を作った
cleancoders.comというサイトのプログラミング動画を見て勉強しています。 英語で、日本語字幕はなく、高価ですがシニアクラスのプログラマーから直接、教えを受ける機会がない自分には貴重な教材です。
Java Case StudyというシリーズではWebサービスをスクラッチからTDDで開発し、ユースケースを一つ実装するまでを思考錯誤の過程も含めて見せてくれます。 コードはGitHubで公開されています。
GitHub - cleancoders/CleanCodeCaseStudy: Clean Code Case Study
設計やコーディングの進め方、テストの書き方、それらの背景にある考え方、Intellijのちょっとしたテクニックなど独学初心者プログラマには情報の宝庫だと思います。
厄介なのは途中からクラスが増えすぎて、話についていけなくなることです。 最初はついていけるのですが途中からアーキテクチャ変更が始まり、クラスがガラっと入れ替わり、数も増えます。
そこで主要なクラスのみピックアップしてクラス図とシーケンス図を作成しました。 最終形を知っていればなんとかついていけます。
同じ動画を見ている人はいないと思いますが、参考になるアーキテクチャなので投稿します。 個人的なメモ程度なので正規のUMLではありませんがご容赦ください。
クラス図
シーケンス図
感想
- 今回の要件においてはPresenterは過剰設計。将来、他のユースケースで生きてくる？
- UseCaseが複数ある前提ならばfactoryを作ってRouterやControllerに渡してもいい気がする。
- codecastSummariesをDelivery依存なコンポーネントとDelivery非依存なコンポーネントに分割（クラス図の赤線）したのに最終的に同じpackageに入れているのはなぜだろう？
- 同じパッケージだけどJARファイルは分割する？
- codecastSummariesの下にもう1階層パッケージを作って分割する予定だった？
シリーズ概要
- ビジネスロジックを作る
- テスト用の仮Webサーバを自作する
- 最初のユースケースの顧客向けデモを完成させる
- アーキテクチャの変更を行う
- Coverageの確認、Dead Codeの削除を行う
- FailするAcceptance TestをPassさせる
後日談
最近、これが「クリーンアーキテクチャ」と呼ばれるアプリケーションアーキテクチャであることを知りました。ここ数年くらい話題になっていって、iOSアプリ開発で有名なVIPERはクリーンアーキテクチャの亜種だそうです。知りませんでした。
こちらがアーキテクチャ図です。
クリーンアーキテクチャについてはこちらのリンクが最高にわかりやすいです。Javaのサンプルがついているのと筆者の考察が最高です。
実践クリーンアーキテクチャ with Java │ nrslib
クリーンアーキテクチャに関して少し噛み砕かれすぎていますが、アプリケーションアーキテクチャ全体から落とし込んで理解するには最高過ぎるのがこちらです。勉強になる。。。
世界一わかりやすいClean Architecture - nuits.jp blog
Presenterについてようやく理解できた気がします。
Java Case StudyではControllerが入力を受け取り結果を返す役割を担っていました。多くのWebフレームワークはこのように入力を受けたオブジェクトが結果を返す構造になっていると思います。このような環境においてはOuput Boundary/Presenterは無理やりねじ込んだ感がいなめませんでした。
一方、アーキテクチャ図を見るとControllerは入力を受け取るだけで結果の処理には関与していません。Presenterが直接、結果を返しています。このように入力を受けたオブジェクトと結果を返すオブジェクトを分離できるフレームワークもあります。このような環境においてはInput Boundaryと対をなすOutput Boundary/Presenterという抽象化レイヤは意味があると感じます。
ではなぜJava Case StudyではOuput Boundary/Presenterをねじ込んでいるのか？想像するにUseCase Interactorをどちらのフレームワークにも対応できる、フレームワーク非依存な構造にするためだと思います。これならフレームワークを引っ越ししてもControllerとPresenter部分だけ書き換えれば済みます。このアーキテクチャにおいて最も重要なUseCase Interactorは影響を受けません。
さらに想像すると、このJava Case Studyシリーズは「Presenterを省略するな！ControllerとPresenterで協調してうまくやれ！」というメッセージなのかと思いました。（省略する気だった人）
