CleanArchitecture_31章_32章.pdf

Transcript

1. CleanArchitecture 31章&32章 YOURMYSTAR　佐々木
2. 31章　ウェブは詳細 導入 ウェブはこの業界で６０年大からずっと続く「振り子」の延長線上にある。振り子の状態は、全ての計算 パワーを中央サーバーにまとめるか、全ての計算パワーを端末に分散させるかを行ったり来たりして いる。 全てのパワーをサーバー側にまとめていてブラウザ側では 何もしていない。 しかしそのうち、ブラウザで実行する 巨大なアプリケーションを書くまでになった。
3. 止まらない振り子 ウェブの歴史：計算機室とパンチカード →緑色の画面→ミニコン、、、、 計算能力がどこに必要になるかを見つけ出さず、 集中と分散の間を行ったり来たりしている アーキテクトとしては長期的な視点で考える。振り子の運動は短期的な問題。 伝えたいこと→ビジネスルールをGUIから切り離す
4. 結論 ウェブ＝GUI＝詳細、ウェブは入出力デバイスの一種 である。 詳細をビジネスロジックの中心から切り離しておきたい。 UIとアプリケーションの間には教会があり、 抽象化できる。 完成した入力データや結果となる出力データを何らかのデータ構造に格納すれば、ユースケースを実 行するプロセスの入力値及び出力値として利用できる。
5. まとめ 画面からビジネスロジックを切り離して、画面は使いやすさなどを追求したほうがいいんだと思う。
6. フレームワークは詳細 フレームワークはアーキテクチャではない。 なかにはそうであろうとしているものもあるが、それでもやはりアーキテクチャではない。
7. フレームワークの作者たち フレームワークの作者はあなたが何に困っているのか知らない。フレームワークの作者が知っている のは作者自身、同僚、友人が抱える問題のみであり、 彼らの問題を解決するためにフレームワークを 作っている。 あなたが抱える問題と作者たちの抱える問題が重なることはある。 重なる部分がそれなりにあるのならフレームワークは便利なものだ！
8. 一方的な結婚 フレームワークの作者と我々の関係は極めて不釣り合いである。 作者は我々に対して何の義務も負う必要がない。 すべてのリスクと負担を背負うのは我々である。（一方的な結婚） しかしフレームワークの作者は、 FWと我々の作るアプリ、FWと我々自身の強い結合を望んでいる。
9. リスク • 依存性のルールに違反する傾向がある。円の最も内側に FWを結合させたがっている。イチゴ 入り込んでしまえば外すことができない。 • プロダクトが成長するにつれて FWの提供する機能では手に負えなくなってくる。 • FWが進化する方向があなたの望む道から外れてしまうかもしれない。なんの利益にもならない バージョンアップ、使っていた機能の廃止、仕様変更。 • 優れたFWに出会った時に乗り換えたくなるかも・・・・
10. 解決策 結論：FWとは一定の距離を保つこと（アーキテクチャの縁の外側にあるものとして扱う） FWはプラグインとして使う。コアのコードにはまぜず、 FWはコンポーネントにまとめて、コアのコードに プラグインする。 Spring ビジネスオブジェクト全体に＠ Autowired→NG Main（最下位コンポーネント）に＠ Autowired→OK
11. 今あなたたちを夫婦として宣言する どう考えてもFWと結合しなければならない時はある。 C++ →STL,Java→標準ライブラリ そのアプリケーションはFWに縛られることになるのファと認識しておく必要がある。
12. まとめ FWに出会ったらアーキテクチャの境界から可能な限り遠ざけるようにしよう。
13. 感想 31章 確かにGUIとビジネスルールは切り離して考えるべきだとは思う。ビジネスルールと実際に使うユー ザーは関係ないのだから。 32章 FWに依存しすぎるなという意味かなと思った。しかし使いやすい FWだと、それありきで考える方向に どうしてもなるため（私は）アーキテクチャと分離しろという言葉は耳が痛かった。