Slide 1
Slide 1 text
誤解 クリーンアーキテクチャ
Slide 2
Slide 2 text
佐藤 功樹（２５）
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
これを書くにあたり
Slide 6
Slide 6 text
これを書くにあたり
本を読みました。
この発表を聞いて「なんかおかしいな～」と思ったら
お気軽にフィードバックをお願いします。
また、発表を聞いて興味を持った方はこの本を読んだ
ことがない人はぜひ読んでみてください。
わりと賛否両論分かれるところがあるので、自分の中
でスタンスを取っておくにも良い一冊です。
わたしの姿勢としては、
このスライドの最後にお伝えします。
Slide 7
Slide 7 text
もくじ
1. 誤解 クリーンアーキテクチャ
2. 物語 クリーンアーキテクチャ
3. 実践 クリーンアーキテクチャ
4. なんかつらい
5. つらくない実装
Slide 8
Slide 8 text
誤解 クリーンアーキテクチャ
Slide 9
Slide 9 text
Sec. 誤解 クリーンアーキテクチャ
誤解１
Slide 10
Slide 10 text
Sec. 誤解 クリーンアーキテクチャ - 誤解１
クリーンアーキテクチャはすごい
クリーンアーキテクチャのでは、
右記の同心円図（通称たまねぎ図）が有名です。
名前がずるいため、なんだか最強のフレームワークの
ように感じます。
画像出典:
Robert C. Martin 「The Clean Architecture」
しかし、クリーンアーキテクチャは数ある技術的な概
念なかの一つでしかありません。
むしろ、すごいと思いすぎるとクリーンな実装に振り
回され、結果時間がかかってしまうことになります。
Slide 11
Slide 11 text
Sec. 誤解 クリーンアーキテクチャ
誤解２
Slide 12
Slide 12 text
Sec. 誤解 クリーンアーキテクチャ - 誤解２
クリーンアーキテクチャは難しい
簡単なことではないですが、
警戒する必要もないという話をします。
そもそも、クリーンアーキテクチャは何を目的をした
モデルなのでしょうか？
ここでは、新規機能の開発が簡単であったり、保守・
運用がやりやすいものが優れているとあります。
単純に、リリースごとに労力が増えていくのであれ
ば、それは優れた設計ではありません。
Slide 13
Slide 13 text
Sec. 誤解 クリーンアーキテクチャ
誤解３
Slide 14
Slide 14 text
Sec. 誤解 クリーンアーキテクチャ - 誤解３
クリーンアーキテクチャは銀の弾丸である
銀の弾丸とは「どういうケースでも撃てば解決する最強
のソリューション」として扱われることがあります。
クリーンアーキテクチャはそうではありません。
画像出典: 漫画「銀の弾」- 南
導入すれば複雑性が増し、SPAの実装などでは冗長な設
計となります。
他にも、初期学習フェーズで手間がかかるために短納期
でのプロジェクトにも不向きです。
エンジニア一人ひとりが、ケースごとに設計を考えてい
くことが大事になります。
Slide 15
Slide 15 text
Sec. 誤解 クリーンアーキテクチャ
誤解４
Slide 16
Slide 16 text
Sec. 誤解 クリーンアーキテクチャ - 誤解４
小規模プロジェクトに向かない
💡 小規模プロジェクトとは
ここでは、１〜５人程度のプロジェクトのことを指します。
とはいえ、メンバーが１０人までならギリギリ小規模って言えるかも。
大規模に導入することで効果が出ると思われがちですが、
キックオフの段階で大規模であることはそうありません。
最初から段階的に実装を進める必要があります。
クリーンアーキテクチャは一つの概念だけではなく、
複数の概念で成り立っています。
一つひとつを注視して、
プロジェクトに導入したいものから導入するべきです。
Slide 17
Slide 17 text
物語 クリーンアーキテクチャ
Slide 18
Slide 18 text
Sec. 物語 クリーンアーキテクチャ
同心円について触れてませんね？
Slide 19
Slide 19 text
Sec. 物語 クリーンアーキテクチャ
触れましょう
Slide 20
Slide 20 text
Sec. 物語 クリーンアーキテクチャ
あるところに、魔法使いの国がありました。
この国では、魔法陣を作って色々な物事をすることを生業にしている人がいました。
Slide 21
Slide 21 text
Sec. 物語 クリーンアーキテクチャ - 円のルール
魔法を行使する際は、魔法陣を書いて実行する必要があります。
Slide 22
Slide 22 text
Sec. 物語 クリーンアーキテクチャ - 円のルール
魔法陣の円の中心部分には、一番大事なルールが書かれています。
Slide 23
Slide 23 text
Sec. 物語 クリーンアーキテクチャ - 円のルール
円の外側に行くにつれて、変更しやすいものが書かれています。
Slide 24
Slide 24 text
Sec. 物語 クリーンアーキテクチャ - 円のルール
この構造にすることで、魔法使いが魔法陣を変更しやすくなります。
Slide 25
Slide 25 text
実践 クリーンアーキテクチャ
Slide 26
Slide 26 text
Sec. 実践 クリーンアーキテクチャ
結果→わかんないよ！
Slide 27
Slide 27 text
実際にコードベースで見る
Sec. 実践 クリーンアーキテクチャ
Slide 28
Slide 28 text
ざっくりこんなのがあるよ
・Entities
・Gateways
・Usecases
・Controller
・Presenter
上記の項目をこれから扱っていきます。
画像出典:
Robert C. Martin 「The Clean Architecture」
Sec. 実践 クリーンアーキテクチャ
細かい部分はここでは取り扱わないので、
知りたいものは書籍や各種サイトにてご覧ください。
Slide 29
Slide 29 text
エンタープライズビジネスルール
Sec. 実践 クリーンアーキテクチャ
Slide 30
Slide 30 text
Entities
エンティティといえば、他の項目でも使われるためそ
ちらを意識する人もいるかもしれません。
正確には、
ビジネスルールをカプセル化、閉じ込めたものです。
ここでは、ビジネスルールのことを指します。
ドメインモデルとも言われ、データベースをオブジェ
クト化したものと囚われがちですが、そうではありま
せん。
参考：ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティ
Sec. 実践 クリーンアーキテクチャ - エンタープライズビジネスルール
Slide 31
Slide 31 text
アプリケーションビジネスルール
Sec. 実践 クリーンアーキテクチャ
Slide 32
Slide 32 text
Usecases
ユースケースは、
・アプリケーション固有のビジネスルール
・DDDにおけるアプリケーションサービス
などを定義します。
エンティティと含めて、
この部分までがドメイン層になります。
Sec. 実践 クリーンアーキテクチャ - アプリケーションビジネスルール
また、外部の層が依存するためのインターフェースも
ここで作成します。
アプリケーション内のAPI的な役回りが主です。
Slide 33
Slide 33 text
インターフェースアダプター
Sec. 実践 クリーンアーキテクチャ
Slide 34
Slide 34 text
インターフェースアダプターとは？
ドメイン層からフレームワークなどへ求められた
データを送る便利な層です。
Sec. 実践 クリーンアーキテクチャ - インターフェースアダプター
インターフェースアダプターおばあちゃん
使いやすいように
２本セットにしたから
・使いやすいようにデータを変換する
・プロトコル（通信規格）を合わせる
・実装をビジネスロジックから関心を分離する
右記ではおばあちゃんがデータを変換しています。
Slide 35
Slide 35 text
Gateways
Gatewaysはひとつの言い方で、Repositoryとも呼ばれ
ます。ユースケースとの接続がなされていれば呼び方
はどっちでも良いみたいです。🙆
リポジトリ（＝倉庫）は、ソフトウェアにおけるデー
タの永続化をするオブジェクトです。
Sec. 実践 クリーンアーキテクチャ - インターフェースアダプター
乱暴な言い方をすると、データの永続化ができればな
んでもよいです。
データベースでも、CSVファイルでもどこのメモリで
もOKです。
揮発するメモリだとだめです（フロントの状態とか）
Slide 36
Slide 36 text
Controller
Controllers は入力をアプリケーションが要求する形に
変更して伝えるのが役目です。
その名の通り、
ゲームのコントローラーのような役割を担います。
Sec. 実践 クリーンアーキテクチャ - インターフェースアダプター
さっきのおばあちゃんで言うところの、人間の
インプットから形式を合わせる外部アダプターです。
おばあちゃん？
0101010…
欲しいものを言う
人間
ABC
Slide 37
Slide 37 text
Presenter
Sec. 実践 クリーンアーキテクチャ - インターフェースアダプター
さて、一番わかりにくい項目です。
なぜ分かりにくいのかというと、ここまではMVCの概
念が理解出来ていれば分かるからです。
Presenterの役割はCとVの間に入れることで、データ
をビュー変換するロジックを担うことです。
なので、Presenter層を取り入れる場合は既存のMVC
からやや格好を崩す形になります。
WEBフロントエンドで言うとバリデーションなどの
ロジックを全部任せることを指します。
Slide 38
Slide 38 text
なんかつらい
Slide 39
Slide 39 text
実装してみたらめっちゃつらい
ここまで解説しましたが、
あんまり直感的ではないですよね。
Sec. なんかつらい
概念一つひとつは理解出来ますが、
コードに落とし込むとなると途端に難しくなります。
これってクリーンなんだっけ？という思考をひとつ挟
むので、速度も出なくなってしまいました。
だんだんクリーンにすることが目的になってしまい、
掃除するためにコーディングしてるんじゃないんだけ
どな・・・となっていきます。 掃除するひと
Slide 40
Slide 40 text
つらくない実装
Slide 41
Slide 41 text
しっかり自分の中の軸を持つ
理解が出来ていれば、
エッセンスは取り入れることができます。
Sec. つらくない実装
ドメイン駆動設計なども流行っているので、
そのあたりだけ抑えつつ進めるのも🙆
最後に、この本の著者である「ボブおじさん」の言葉
を引用して終わります。
速く進む唯一の方法は、うまく進むことである。
──RobertC.Martin
Slide 42
Slide 42 text
余談
Slide 43
Slide 43 text
余談
パロディです
オライリーの詳解シリーズにインスピレーションを受
けて書きました。
このあたりも面白いのでぜひ！気になる一冊手にとっ
て見てください。
オライリー本はいいぞ。