コンポーネント設計って何だろう

コンポーネント設計って 何だろう 設計ナイト June 14, 2024 Takeshi Yonekubo

About Me • 米久保 剛（よねくぼ たけし） • SIer勤務のアーキテクト • X: @tyonekubo • note: https://note.com/yonekubo 2024年7月22日発売！

§1.コンポーネントとは何？

マーチン・ファウラー モジュールとは、明確に定義された一部のサブセットを 理解するだけでシステムを変更できるようにソフトウェ アシステムを分割したものと定義します。 コンポーネントはモジュールの一形態であり、独立して 置換できるという追加の特性を備えています。 出典 martinFowler.com “Software Component” より筆者抄訳 https://www.martinfowler.com/bliki/SoftwareComponent.html

• https://www.martinfowler.com/bliki/SoftwareComponent.html

ロバート・C・マーチン （アンクル・ボブ） コンポーネントとは、デプロイの単位のことである。 システムの一部としてデプロイできる、 最小限のまとまりを指す。 Javaならjarファイル、Rubyならgemファイル、 .NETならDLLなどがそれにあたる。 出典 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』 第12章

SWEBOK V3.0 ソフトウェア・コンポーネントとは、独立した単位であ り、明確に定義されたインターフェースと依存関係を持 ち、独立して構成・配置することができる。 出典 IEEE COMPUTER SOCIETY “SWEBOK V3.0” より筆者抄訳 http://swebokwiki.org/Chapter_2:_Software_Design

C4 model コンポーネントとは、関連する機能をまとめて、明確に定義さ れたインターフェースの背後にカプセル化したものです。Java やC#のような言語を使用している場合、コンポーネントを最 も簡単に考える方法は、インターフェースの背後にある実装ク ラスの集まりとして捉えることです。コンポーネントのパッ ケージ化の方法（例えば、1つのJARファイルに1つのコンポー ネントを含めるか、DLLや共有ライブラリに複数のコンポーネ ントを含めるかなど）は、別の独立した問題です。 出典 ” The C4 model for visualising software architecture” より筆者抄訳 https://c4model.com/

• https://c4model.com/

本日のトークはこっち 寄りで話します SWEBOK C4 model 明確に定義されたインター フェースを持ち、機能を提供す るまとまり ファウラー 置換可能性 デプロイ可能性 アンクル・ボブ

ユースケースなど、 ユーザーによって意味の ある機能性を提供 アプリケーション や サービス プログラミング言語の 最小単位 > コンポーネント 独立した「振る舞い」を 提供する単位 ≥ クラスや関数 ※1つのクラスや関数が コンポーネントとなる 場合もある

§2.コンポーネント設計とは

どうやって コンポーネントを設計する？

ICONIXアプローチ • 機能要求をクラス構造や相互作用に落とし込む分析・ 設計手法 分析と設計のギャップ を埋める予備設計 出典 『ユースケース入門 ユーザマニュアルからプログラムを作る』第1章, 図1-2

ロバストネス分析 • 三種類のオブジェクト コントロール オブジェクト 境界 オブジェクト 実体 オブジェクト 出典 『ユースケース入門 ユーザマニュアルからプログラムを作る』第4章, 図4-6

ロバストネス分析の目的 サニティチェック ・ユースケース記述の正しさ ・オブジェクト群との整合性 完全性チェック ・ユースケースに必要な振る舞いが もれなく表現されているか オブジェクトの識別 ・ドメインモデルの洗練 出典 『ユースケース入門 ユーザマニュアルからプログラムを作る』ピアソン (2001) 第4章, 図4-6

ロバストネス分析を 設計に落とし込むには

アプリケーションの振る舞い • 二種類のロジック 処理フローロジック 処理の流れ、手続きを表現 • アプリケーションサービス • ユースケース 中核ロジック ビジネスルールを表現 • ドメインオブジェクト • ドメインサービス 出典 『ユースケース入門 ユーザマニュアルからプログラムを作る』ピアソン (2001) 第4章, 図4-6

例 入力ポートが表現する ユースケースの 振る舞い アプリケーションサービ スが実現する 処理フローロジック ドメインオブジェクト の振る舞いとして実現 される中核ロジック データの永続化という 関心事は出力ポートに 処理を委譲する 出典 『オブジェクト開発の神髄 UML2.0を使ったアジャイルモデル駆動開発のすべて』第10章, 図10.9

Clean Architecture Interface adapters Use cases Entities Controller Repository DB Web Presenter

Clean Architecture Interface adapters Use cases Entities Controller Web Repository この図は、アンクル・ボブのCA本の図 22-2「データベースを使ったウェブベー スのJavaシステムの典型的なシナリオ」 に近い Presenter DB

あくまで「一つの例」

よくある過ち(1) これがClean Architecture だと考えてしまう ⇒応用が効かなくなる （Web APIだったら？バッチだったら？）

よくある過ち(2) ステレオタイプを 絶対視してしまう ⇒肥大化していくコンポーネント

設計の詳細化が必要

Divide and Conquer コンポーネントの責務（＝期待される振る舞い）を、 小さく分割する （例） • アプリケーションサービスの分割 • ヘルパーに処理を委譲 • ユーティリティ

ドメインロジックの コンポーネントの詳細化 ココ

ドメインモデルパターンを使う目的 問題領域を分析して得られた メンタルモデルの写像を作る メンタルモデルと乖離の 少ない設計モデルを作る

解決空間に設計を最適化する

デザインパターンの例(1) • ファーストクラスコレクション →「顧客のコレクション」という概念はメンタルモデル には存在しないが、便宜的に導入することでコードの見 通しがよくなる class Customers { List<Customer> customers; void add(Customer customer) { ... } void removeIfExist(Custoemr customer) { ... } int count() { ... } Customers importantCustomers() { ... } } 出典 『現場で役立つシステム設計の原則 変更を楽で安全にするオブジェクト指向の実践技法』第1章

デザインパターンの例(2) • Visitorパターン →Visitorをacceptするって何？！ →複雑なオブジェクト構造を走査するアルゴリズムを分 離することでコードの見通しがよくなる 出典 ウィキペディア「Visitor パターン」 https://ja.wikipedia.org/wiki/Visitor_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

• https://ja.wikipedia.org/wiki/Visitor_パターン

コンポーネント設計: アウトサイドインで 抽象度を段階的に下げて 振る舞いを分割する

Lv.1 抽象度(高) ~ ユースケース

Lv.2 抽象度(中) 振る舞いを分割

Lv.3 抽象度(低) さらに振る舞いを分割 Foo Bar

まとめ

①コンポーネントは、何らかの期待される振る舞いを 提供する責務を持つ ②コンポーネントの抽象度は様々であり、入れ子構造 を取る ③コンポーネント設計はアウトサイドインのアプローチ で段階的に進めていく

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

参考文献 『ユースケース入門 ユーザマニュアルからプログラムを作 る』 ダグ・ローゼンバーグ、 ピアソン・エデュケー ケンドール・スコット ション（2001） 『オブジェクト開発の神髄 UML2.0を使ったアジャイルモ デル駆動開発のすべて』 Scott W. Ambler 日経BP（2005） 『Clean Architecture 達人に学ぶソフトウェアの構造と設 計』 Robert C .Martin KADOKAWA（2018） 『現場で役立つシステム設計の原則 変更を楽で安全にする オブジェクト指向の実践技法』 増田 亨 技術評論社（2017）