【オンライン】Clean Architecture 達人に学ぶソフトウェアの構造と設計 輪読会 #16

Transcript

1. Clean Architecture 達人に学ぶソフトウェアの 構造と設計【輪読会】 第16回：第33章~第34章 2020/12/23 @masyus_work
2. 第33章 事例： 動画販売サイト
3. 第33章 事例：動画販売サイト 1. アーキテクチャを決めるための第一 歩は - アクターとユースケースを見 つけること 2. 抽象ユースケース - 図33-1点線部。共通化の道 を探るのが得策
4. 第33章 事例：動画販売サイト 1. 抽象ユースケース - 図33-2赤枠 2. ただし、デプロイ単位は様々な切り 口を維持しておく - 将来的にデプロイ方法を柔軟 に変更できて良い 【↑分割方針】 - 単一責任の原則（SRP）に基づくアクターによる分割 - 依存性のルールによる分割
5. 第34章 書き残したこと 設計やコーディングに関する そのほかのアプローチ （クリーンアーキテクチャ以外）
6. 第34章 書き残したこと 1. レイヤードアーキテクチャ - 水平方向 - ソフトウェア規模が大きくなると、3つの パッケージングに分けるのでは手に負 えなくなる - ビジネスドメインに関しては何も叫ばな い
7. 第34章 書き残したこと 2. 機能によるパッケージング - 垂直方向 - パッケージングは1つ - ビジネスドメインに関して叫べる
8. 第34章 書き残したこと 3. ポートとアダプター - ビジネス（ドメイン）に関するコードを技術的な 実装から切り離して独立させること
9. 第34章 書き残したこと 4. コンポーネントによるパッケージング Controllerがリポジトリに直接アクセスしちゃった （つまりルールを無視して実装してしまった） - 何らかのガイドラインが必要になる - → コンポーネントによるパッケージング
10. 第34章 書き残したこと 4. コンポーネントによるパッケージング - 粒度の粗いコンポーネントに関連する全て の責務をひとつのJavaパッケージにまとめ ることを目指す - 図34-5のようなケースの場合、注文に関す るコードを書きたければ OrdersComponentだけを見ればOKなス タンスにしてしまうという方策
11. 第34章 書き残したこと 余談：CQRS（コマンドクエリ責務分離）とは - データの更新とデータの読み取りを切り離 すパターン - = Command Query Responsibility Segregation
12. 第34章 書き残したこと 5. 悪魔は実装の詳細に宿る 6. 組織化かカプセル化か - publicの乱用 → パッケージは事実上無い に等しくなってしまう - → 今まで解説した4つのアーキテクチャ手 法が意味なくなってしまう
13. 第34章 書き残したこと 適切にアクセス範囲を絞り込みましょう
14. 第34章 書き残したこと 7. そのほかの分割方法 - Javaの場合 - OSGi - Java 9 モジュールシステム - それぞれ別のソースコードツリーに分割する - 例 - ビジネスやドメイン用のソースコード - ウェブ用のソースコード - データ永続化用のソースコード
15. 第34章 書き残したこと まとめ - いくらうまい設計をしても、その実装方法の複雑さを考慮しなければ、 あっという間に設計が崩れてしまう - チームの規模やメンバーのスキル、ソリューションの複雑さ、時間と予 算の制約を考慮する必要あり
16. 輪読会 第16回 Fin...