やってみてわかった クリーンアーキテクチャの勘所

30.6K Views

May 22, 24

スライド概要

Findyさんのイベント「アーキテクチャを突き詰める Online Conference」のLT登壇資料です。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

やってみてわかった クリーンアーキテクチャの勘所 アーキテクチャを突き詰めるONLINE CONFERENCE 公募LT選手権 MAY 22, 2024 TAKESHI YONEKUBO

2.

ABOUT ME 米久保 剛 Takeshi Yonekubo  SIerに勤務  業務パッケージソフト開発のリードアーキテクト  普段使っている言語は Java/Groovy/TypeScript  X: @tyonekubo  note: https://note.com/yonekubo  2024年7月22日に翔泳社さんから本を出します

3.

私とクリーン アーキテクチャ(CA)

4.

2017年11月 原著発売 『Clean Architecture A Craftsman’s Guide to Software Structure and Design』 2018年7月 日本語訳発売 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』 2018年〜2019年 ソフトウェア設計界隈でCAが流行 2019年夏 新規プロダクト開発で、CAを採用 振り返って みる 2021年1月 プロダクトのリリース 〜2024年現在 継続開発中

5.

なぜCAを選んだか (動機)

6.

以下を改善したい ❶コードの見通しの悪さ ❷テストのしづらさ

7.

❶コードの見通しの悪さ Presentation Layer 業務ロジックがプレゼン テーション層やデータア クセス層に滲み出す Domain Layer Data Access Layer トランザクションスクリ プトになりがち、業務ロ ジックの重複

8.

❷テストのしづらさ Presentation Layer WebやDBなどテクノロ ジーに依存したコードは テストを書きにくい Domain Layer Data Access Layer 何を対象に、どんな粒度 でユニットテストを書く べきなのか指針がない インテグレーションテス トは考えやすいが、実装 コスト・実行コストが高 い

9.

苦労した点 具体的にCAはどう実装 すればよいか?

10.

具体的にどう実装すべきかにつ いて、書籍で多くは触れられて いない 当時(2019年)はCAに関する 情報やサンプルは少なかった

11.

書籍の図22-2「データ ベースを使ったウェブ ベースのJavaシステムの 典型的なシナリオ」のク ラス図を読み解いて、基 本的にこれに倣う形で実 装した 図の出典: Robert C. Martin著『Clean Architecture 達人に学ぶソフトウェアの構造と設計』ドワンゴ(2018)

12.

良かった点 方針と詳細の分離

13.

方針 <<interface>> データ出力Port XXデータを出力す るUseCase 詳細 Web CSV出力 Presenter バッチ CSV出力 Presenter • 「方針」と「詳細」を分離し、 抽象に依存するようにする • 上位の方針であるユースケー スは、具体的な出力の実装を 気にすることはない • 例)画面からのCSVダウン ロードと、バッチ処理での一 括エクスポートは、それぞれ 具象プレゼンターを実装する ことで対応できた

14.

良かった点 テスト容易性

15.

インタフェース アダプター層 エンティティ層 ユースケース層 Domain Service Controller Validator UseCase Presenter Dao データベース Domain Object Domain Object Domain Object DataAccess or Service Repository Gataway • 実装の詳細に依存しないため、 テストコードが書きやすく なった • テスト戦略が立てやすくなっ た • ドメイン層を中心に、まと まった振る舞いの単位でユ ニットテストを記述 • 大きな振る舞いの正しさはイ ンテグレーションテストやE2E でカバー

16.

良かった点 叫ぶアーキテクチャ

17.

• 従来の、レイヤー単位のパッケー ジ分割でなく、CA流に機能単位の パッケージ分割を行った • 凝集性が高まり、保守性も向上 →モノリスからの脱却に向けた、 小さな一歩

18.

改善したい点 クラス数の増大

19.

• インターフェースやクラスの数が 増大し、レイヤー間のデータ変換 も多くなるため、実装の手間がか かる • 特に、読み取り・参照系のユース ケースはドメイン層が「スカス カ」になりがち →CQRSを導入し、読み取りと 書き込みでモデルやO/Rマッパー を分離することも検討すべき

20.

改善したい点 モジュール間結合

21.

インタフェース アダプター層 エンティティ層 ユースケース層 モジュール境界 DA REPO UC DAO ① モジュールA UC DA データベース モジュールB DAO ② データベース REPO • ユースケース層でのモジュー ル境界をまたがった依存(矢 印①) • DBのテーブルレベルで間接 的に依存(矢印②) 上記によって、不用意にモ ジュール間の結合度が高く なってしまっている →モジュラーモノリス化を 検討する必要性

22.

【結論】 CAとは何なのか 図の出典: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

23.

CAにより、「ドメインを中心に据える」 「方針と詳細を分離する」というコンセ プトと枠組みをインストールすることが できる。 CAは、あるべきモジュール分割やコン ポーネント分割を支援する土台に過ぎな い。設計と真摯に向き合うことが重要。

24.

ご拝聴ありがとう ございました