CleanArchitecture17章＆18章

CleanArchitectureの17章と18章です

Transcript

1. CleanArchitecture 17章&18章 Sasaki
2. 17章　バウンダリー：境界線を引く ソフトウェアの要素を分離し、お互いのことがわからないように制限する →依存関係がない方がよいって意味だと解釈した メリット・目的：システム構築・維持の人件費を最小限に抑えることができる 人々のパワーを奪うもの：結合・・・それも早すぎる決定との結合
3. 失敗例　 p社 オブジェクトのインスタンスを分ける、サーバの台数の意思決定早すぎた。 →開発の労力がすごくかかった w社 SOAを視野に入れたツールを導入するのが早すぎた →伝播の遅延・キューの待ち時間ができた・いちいちサービスを立ち上げないといけない
4. 成功例　FitNesse データはスタブ→必要になったら本物のDBに接続 ビジネスツールとデータベースの間に境界線を引いたことでDBの洗濯を１年以上遅らせ ることができた。DBを使っていない間厄介な問題（スキーマ、クエリ、パスワードなど）に １８ヶ月も直面することがなく開発を進めることができた。
5. 成功から学ぶ 「重要なもの」と「重要でないもの」を分ける 重要…ビジネルスール 重要ではない…GUIツール（入出力はビジネスルールに直接関係ない）、DB（データの もビジネスルールと直接関係ない、スタブを使えばいい）
6. プラグインアーキテクチャ プラグインいよってスケーラブルで保守可能なシステムアーキテクチャを確立することが できる！ UI・SOAなどをプラグインとして扱うことで様々な技術に置き換え可能 →プラグイン構造を前提に着手することで変更に強いシステムになる そのためには境界線をきちっと引くことが大事である →単一責任の原則が教えてくれる
7. 17章の結論 システムのビジネス要件と関係のないところ（db、フレームワーク、DI）の意思決定は遅く てもいい。 コアのビジネスに関係しないところはプラグインにしておく。
8. 18章　境界線の解剖学 ソフトウェアコンポーネント間の境界を超える通信はいろいろな形のものがある。 • ソースコード • 恐怖のモノリス • デプロイコンポーネント • スレッド • ローカルプロセス • サービス
9. ソースコード ソースコードのモジュールを変更すると他のソースコードのモジュールも変更や再コンパ イルをするなどして、デプロイし直す必要があるかもしれないからだ。
10. 恐怖のモノリス .jarや.exeなどの内部的な話？だと解釈した（正直よくわかってない） 下位レベルのクラス→上位レベルのクラス 実行時の依存性とコンパイル時の依存性の両方で同じ方向を向くため
11. デプロイコンポーネント 動的リンクライブラリのこと
12. スレッド 実行のスケジュールや順序を整理する方法
13. ローカルプロセス 上位コンポーネントの一種 ローカルプロセスの境界を超える通信：OSのシステムコール、データのマーシャルとアン マーシャr、プロセス間のコンテキストスイッチetc….
14. サービス 一般的にコマンドラインや同等のシステムコールで開始されるプロセスのこと。 ローカルプロセスと同じルールが適用される。下位レベルのサービスは上位レベルの サービスにプラグインされるべきである。
15. まとめ 下位レベルのプロセスを上位レベルのプロセスのプラグインにすることが目的である。 システムの境界を意識して開発をしたことがないので正直ピンとこなかった