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

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

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

• https://note.com/yonekubo

私とクリーン アーキテクチャ（CA）

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年現在 継続開発中

なぜCAを選んだか （動機）

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

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

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

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

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

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

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

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

良かった点 テスト容易性

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

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

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

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

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

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

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

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

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

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