クリーンアーキテクチャ輪読会資料 27-29章

参加しているコミュニティ、Challeng-Every-Monthの輪読会で作成した資料。

Transcript

1. CA輪読会 27章-29章 2020/3/16(月) 22:00- 発表者:koji/メガネ男
2. 27章 サービス：あらゆる存在 1/4 • サービスアーキテクチャ　 　アーキテクチャは上位レベルの方針と下位レベルの詳細を分離し、を依存性の ルールに従う境界によって定義されるものである。 　サービスを使用すること＝アーキテクチャではない。 　それはただのプロセスやプラット フォームの境界を超える関数呼び出しに 過ぎない、とボブおじさんは断じる。 2
3. 27章 サービス：あらゆる存在 2/4 • サービスアーキテクチャ　 　サービス毎にアプリケーションが別れていることがメリットと言われているけど、リ ソースやデータを介して間接的に繋がっている。 　サービスごとに専属のチームがつき、スケーラブルであることがメリットと言われ ているが、サービスアーキテクチャだけがスケーラブルなわけではないし、開発・デ プロイ・運用の調整が重荷になることもある。 3
4. 27章 サービス：あらゆる存在 3/4 • タクシー配車システムの例 　状況：タクシーの検索、選択、発注サービスを各チームが保守・運用・開発してい る。 　ここに、すべての動作に影響を与える新機能を追加すると、すべてのサービスは 結合していることから、すべてのサービスを変更する必要が生じる。 　例：子猫の宅配機能。ネコアレルギー配慮のため、シフトや配車のシステムに影 響を及ぼす） 4
5. 27章 サービス：あらゆる存在 4/4 • 　でもSOLIDの設計原則を慎重に検討すれば独立して開発・デプロイが可能。 • 　新機能のデプロイは、再デプロイしなくても、新しいファイルをロードパスに追加す るだけで済む。→オープンクローズドの原則 • 　アーキテクチャの境界は、サービスではなく、サービス内部のコンポーネントで決 まる。 5
6. 28章 テスト境界 1/3 • 　テストはシステムの一部であり、アーキテクチャの観点からは、対象、規模に関わ らず、すべてのテストは同じである • 　テストは依存性のルールに従うし、 アーキテクチャの円の最も外側にある • 　テストはコンポーネントに常に依存するし、独立してデプロイ可能な、最も独立した システムコンポーネントである。 6
7. 28章 テスト境界 2/3 • 　テストは普段デプロイしないので、設計と無関係と考えられがち。 　システム安定化のため、設計段階でテストまで考慮する必要がある。 • 　脆弱なテストの問題 　共通のシステムコンポーネントを変更すると、何百や何千というテストが壊れる可 能性がある。 　解決策は、変化しやすいものに依存しない設計を行うこと。 　変化しやすい見た目の部分である GUIに依存すると、テストまでコロコロ 変わってしまいテストが手間になり、 テストがおろそかになるかも！ 7
8. 28章 テスト境界 3/3 • 　プロダクトのクラスやメソッドが変わると大量のテストを変更することになるので、 テストは脆弱になり、プロダクトのコードは柔軟性を失っていく。 • 　テスト段階から使用できるAPIを作成し、検証すればよい。 　APIを使えば開発の影響をテストに与えずに済む。 • 　ただし、テストAPIが完成物のシステムにデプロイされると危険なので、独立したコ ンポーネントに格納すべし。 8
9. 29章 クリーン組込みアーキテクチャ 1/3 • 　ソフトウェアは消耗しないが、ファームウェアやハードウェアは時代遅れになる。 　その結果新しいソフトウェアが必要になる。 • 　時代遅れになりやすいファームウェアは少なくして、ソフトウェアを多くすることが 望ましいのに、組み込みエンジニアでないエンジニアもファームウェアを書いてい る、とボブおじさんは憤慨。 　組み込みソフトウェアのアーキテクチャをクリーンにして、寿命の短いファームウェ アではなく、寿命の長いソフトウェアに注力しよう。 9
10. 29章 クリーン組込みアーキテクチャ 2/3 • 　組み込みソフトウェアは動作すること、正しいこと、速く動くパフォーマンスが優先 され、長寿となるようクリーンなコードを作ることは考慮されていない。 • 　組み込みエンジニアは、ターゲットハードウェアのボトルネック * という問題があ る。 * ハードウェアの完成を待ってからコードを実行する必要があったり、ハードウェア に欠陥があるとコードの実行に支障をきたしたりといった、必要他のエンジニアが 気にしなくて済んでいる制約事項のこと。 10
11. 29章 クリーン組込みアーキテクチャ 3/3 • 　管理できていないファームウェアやハードウェアの依存関係によって、ソフトウェア が内部から破壊される可能性もある。 • 　ファームウェアとソフトウェアは明確に区分すべき。 　OSはファームウェアとソフトウェアを分離する(HAL)。 　クリーン組み込みアーキテクチャは買収等により 変わりかねないOSと、 ソフトウェアも 区分する(OSAL)。 11