SlideShare a Scribd company logo
世界一わかりやすいClean Architecture
~ 誤解されがちな二つのことと、おさえるべき二つのこと ~
Atsushi Nakamura
ふたつ質問させてください
Copyright 2019 @nuits_jp Slide 2
この図を見たことはありますか?
Copyright 2019 @nuits_jp Slide 3
書籍読んでみましたか?
Copyright 2019 @nuits_jp Slide 4
Easiest Clean Architecture
Today’s Goal
Today’s Goal
全員が
「クリーンアーキテクチャチョットデキル」
ようになること
Easiest Clean Architecture
Overview
Overview
Slide 8Copyright 2019 @nuits_jp
Clean Architectureの次の点についてお話させていただきます。
• 誤解されがちな二つのこと
• おさえるべき二つのこと
Easiest Clean Architecture
注意事項
注意事項
Slide 10Copyright 2019 @nuits_jp
今日お話しすることは、あくまで私の解釈です
• 極端に要約しているので、これがすべてではありません
• 書籍の記載とやや矛盾する点もあります
しかし、私は今日お話しする二つこそ、Clean Architectureの
本質だと思っています。
異論・反論大歓迎
Slide 11Copyright 2019 @nuits_jp
異論・反論大歓迎です。※
オンライン・オフラインいずれでも、ぜひご意見を聞かせてください。
ぜひ議論しましょう!
※ 聞く耳持たないマサカリはご遠慮ください
Easiest Clean Architecture
About Me
About Me
Copyright 2019 @nuits_jp Slide 13
中村 充志 / Atsushi Nakamura
• リコージャパン株式会社 所属
• Enterprise(おもに金融)系SIerのITアーキテクト
• 「持続可能なソフトウェア」の探求がライフワーク
• 2019年の目標
• 「世界一わかりやすいClean Architecture」で登壇したい
• 「xUnit & Moqハンズオン」開催
• Blog http://www.nuits.jp
• Blog(英語) https://blog.nuits.jp
• Twitter @nuits_jp
Easiest Clean Architecture
誤解されがちな二つのこと
Clean Architectureといえば・・・
出典:TheCleanArchitecture
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
この図が良くできてい過ぎて誤解を招く
Copyright 2019 @nuits_jp Slide 16
ひとつ目の誤解
Clean Architectureとは
「レイヤーをこれらに分割しろ」
という意味でもない
「関心をControllerやUse Case, Entityに分離しろ」
という意味ではないし
ふたつ目の誤解
「PresentationをMVC的に分離しろ(MVVMなどの否定)」
という意味ではないし
「データや処理の流れを一方通行にしろ」
という意味でもない
Copyright 2019 @nuits_jp Slide 18
MVC Model(出展Wikipedia)
では、どういう意味か?
Copyright 2019 @nuits_jp Slide 19
図の解釈
「依存性は、内側(上位レベルの方針)だけに
向かっていなければいけない。」※
Slide 20
※出典:Clean Architecture 達人に学ぶソフトウェアの構造と設計
図の解釈
こうすればよい ※
内側の変化に応じて、外側を呼び出したい場合どうすればよいのか?
Slide 21
※ より厳密な意図は後述
Easiest Clean Architecture
それあってますか?
はい(当者比)
-The architecture rules are the same! -
(邦訳:アーキテクチャのルールはどれも同じである!)
著者は明言しています
Copyright 2019 @nuits_jp Slide 24
すべてが同一アーキテクチャに帰結するとすれば
以下は、あくまで一例であることは自明
• レイヤーが4つ※1
• UIがMVC的である
• Web限定
• Output PortはUse Caseとの間「だけ」に
ある※2
• 中央がDomainじゃなくてEntities
※1 とは限らないと書籍にも明記されている
※2 eventみたいなPub/SubがUseCase限定じゃ困っちゃう
あくまで例示であると取れる記載もある
Clean Architecture説明の冒頭に、著名なアーキテクチャ(Hexagonal, Onion,
etc...)には類似の共通点が見られるとある。
そして続けてこう記載されている。
The diagram in Figure is an attempt at integrating all these architectures into a single
actionable idea.
(邦訳:図は、これらのすべてのアーキテクチャを単一の実行可能なアイデアに統合し
たものである。)
該当の図は、アーキテクチャは全てClean Architectureで説明可能であることを
例示したモデルであり、Clean Architectureを採用したソフトウェアの具体例の
一つにすぎない
Copyright 2019 @nuits_jp Slide 26
どんなソフトウェアにも適用可能な
普遍的なアーキテクチャである
だって↓だって言うし
-The architecture rules are the same! -
(邦訳:アーキテクチャのルールはどれも同じである!)
Chean Architectureとは
Copyright 2019 @nuits_jp Slide 27
Easiest Clean Architecture
おさえるべき二つのこと
ひとつ目
「依存性は、より上位レベルの方針にのみ向けよ」
ふたつ目
「制御の流れと依存方向は分離しコントロールせよ」
おさえるべき二つのこと
Copyright 2019 @nuits_jp Slide 29
ひとつ目
「依存性は、より上位レベルの方針にのみ向けよ」
ふたつ目
「制御の流れと依存方向は分離しコントロールせよ」
おさえるべき二つのこと
Copyright 2019 @nuits_jp Slide 30
Easiest Clean Architecture
さあ具体例を見てみよう!
• SQL ServerのサンプルDB AdventureWorksを利用します
• プロダクト別の総売上をCSV出力するコンソール アプリ
Overview
Copyright 2018 @nuits_jp Slide 32
Software Architecture
ではコードを見てみよう!
Copyright 2019 @nuits_jp Slide 34
Not Clean Architecture
Copyright 2019 @nuits_jp Slide 35
Not Clean Architecture
Copyright 2019 @nuits_jp Slide 36
依存方向
凡例
Software Architecture
依存方向
凡例
Not Clean Architecture
Copyright 2019 @nuits_jp Slide 38
依存方向
凡例
という訳で修正してみましょう
Copyright 2019 @nuits_jp Slide 39
これでCleanArchitectureになったでしょうか?
Copyright 2019 @nuits_jp Slide 40
Copyright 2019 @nuits_jp Slide 41
依存方向
凡例
Clean Architecture ?
Clean Architecture ?
Slide 42
Copyright 2019 @nuits_jp Slide 43
依存方向
凡例
Clean Architecture ?
Not Clean Architecture
Copyright 2019 @nuits_jp Slide 44
依存方向
凡例
Gatewayはこのままという選択肢はありですが・・・
Copyright 2019 @nuits_jp Slide 45
Software Architecture
依存方向
凡例
DBを呼び出さないといけないのに無理じゃない?
Copyright 2019 @nuits_jp Slide 47
• SQLを利用しないという意味ではない
• RDBというアーキテクチャには依存する
• 永続化データのスキーマに依存しないという意味
DBからGatewayへ依存させるとは?
Copyright 2019 @nuits_jp Slide 48
Not Clean Architecture
Copyright 2019 @nuits_jp Slide 49
依存方向
凡例
Gatewaysのクラス図とER図
Copyright 2018 @nuits_jp Slide 50
dm SalesOrderDetail and Product
Product
«column»
*PK ProductID: int
* Name: nvarchar(50)
* ProductNumber: nvarchar(25)
* MakeFlag: bit = 1
* FinishedGoodsFlag: bit = 1
Color: nvarchar(15)
* SafetyStockLevel: smallint
* ReorderPoint: smallint
* StandardCost: money
* ListPrice: money
Size: nvarchar(5)
FK SizeUnitMeasureCode: nchar(3)
FK WeightUnitMeasureCode: nchar(3)
Weight: decimal(8,2)
* DaysToManufacture: int
ProductLine: nchar(2)
Class: nchar(2)
Style: nchar(2)
FK ProductSubcategoryID: int
FK ProductModelID: int
* SellStartDate: datetime
SellEndDate: datetime
DiscontinuedDate: datetime
* rowguid: uniqueidentifier = newid()
* ModifiedDate: datetime = getdate()
SalesOrderDetail
«column»
*pfK SalesOrderID: int
*PK SalesOrderDetailID: int
CarrierTrackingNumber: nvarchar(25)
* OrderQty: smallint
*FK ProductID: int
*FK SpecialOfferID: int
* UnitPrice: money
* UnitPriceDiscount: money = 0.0
* LineTotal: numeric(38,6)
* rowguid: uniqueidentifier = newid()
* ModifiedDate: datetime = getdate()
クラス図 ER図
Gatewaysが完全にデータベースの文脈で記述されている
Gatewaysのクラス図とER図
Copyright 2018 @nuits_jp Slide 51
dm SalesOrderDetail and Product
Product
«column»
*PK ProductID: int
* Name: nvarchar(50)
* ProductNumber: nvarchar(25)
* MakeFlag: bit = 1
* FinishedGoodsFlag: bit = 1
Color: nvarchar(15)
* SafetyStockLevel: smallint
* ReorderPoint: smallint
* StandardCost: money
* ListPrice: money
Size: nvarchar(5)
FK SizeUnitMeasureCode: nchar(3)
FK WeightUnitMeasureCode: nchar(3)
Weight: decimal(8,2)
* DaysToManufacture: int
ProductLine: nchar(2)
Class: nchar(2)
Style: nchar(2)
FK ProductSubcategoryID: int
FK ProductModelID: int
* SellStartDate: datetime
SellEndDate: datetime
DiscontinuedDate: datetime
* rowguid: uniqueidentifier = newid()
* ModifiedDate: datetime = getdate()
SalesOrderDetail
«column»
*pfK SalesOrderID: int
*PK SalesOrderDetailID: int
CarrierTrackingNumber: nvarchar(25)
* OrderQty: smallint
*FK ProductID: int
*FK SpecialOfferID: int
* UnitPrice: money
* UnitPriceDiscount: money = 0.0
* LineTotal: numeric(38,6)
* rowguid: uniqueidentifier = newid()
* ModifiedDate: datetime = getdate()
クラス図 ER図
Gatewaysが完全にデータベースの文脈で記述されている
実際にはこの4項目しか
必要ない
たとえば・・・
• 他機能の変更で列が増える
• 影響がほぼないことは分かりきっている
• しかし回帰テストはせざるを得ない
テーブルの構造にダイレクトに依存してしまうと・・・
Copyright 2019 @nuits_jp Slide 52
Software Architecture
依存方向
凡例
ひとつ目
「依存性は、より上位レベルの方針にのみ向けよ」
ふたつ目
「制御の流れと依存方向は分離しコントロールせよ」
おさえるべき二つのこと
Copyright 2019 @nuits_jp Slide 54
本質的に大切なのは文脈である
Copyright 2019 @nuits_jp Slide 55
Not Clean Architecture
Copyright 2019 @nuits_jp Slide 56
依存方向
凡例
ここで言うGatewaysのDB依存とは
✖ DBを呼び出しているから
〇 DBの文脈(スキーマ)で記述されているから
Not Clean Architecture
Copyright 2019 @nuits_jp Slide 57
依存方向
凡例
DBがGatewaysの文脈で定
義されていればよい
???
CQRSを使え
Copyright 2019 @nuits_jp Slide 58
CQRS :Command-Query Responsibility Segregation
データベースの操作を次のふたつの責務に完全に分離する方法論
1. データベースを更新するCommand
2. データベースを参照するQuery
今回のケースはQueryに該当するため
Gatewayの文脈でQuery用のDBオブジェクトを用意します。
CQRSとは
Copyright 2019 @nuits_jp Slide 59
完ぺきなCQRSを適用するのは難しい。
また、場合によってはオーバースペックでさえある。
1. CommandとQueryのデータソースの完全分離
2. ドメインイベント
3. 非同期メッセージ
4. イベントソーシング
5. 結果整合性
6. などなど
そこで今日は、データベースのViewを使った軽量な方法論を紹介します※
※ 必ずしもViewを使えという訳ではない
とはいえ・・・
Copyright 2019 @nuits_jp Slide 60
これがCleanなArchitectureだ!
Copyright 2019 @nuits_jp Slide 61
※ 言い過ぎです
Clean Architecture
Copyright 2019 @nuits_jp Slide 62
依存方向
凡例
Clean Architecture!
Slide 63※ 言い過ぎでもないです
このアーキテクチャの完璧な再現性を見てください!
CQRSと類似概念にCQSがある
• コマンドクエリ分離原則(Command-Query Separation)
雑に言うと・・・
• CQRSはデータソースに対するパターン
• CQSはクラスに対するパターン
DBの文脈をGatewayで吸収する選択をする場合はCQSも検討する
CQSについて
Copyright 2019 @nuits_jp Slide 64
Easiest Clean Architecture
制御の流れと依存関係の分離
制御の流れと依存関係の分離
凡例
制御の流れ
依存方向
アプリケーション
コード
データベース
オブジェクト
一般的に
制御の流れ=依存方向
になりがち
<<具象概念>> <<具象概念>>
Slide 66
制御の流れと依存方向は分離しコントロールできる
Copyright 2019 @nuits_jp Slide 67
制御の流れと依存関係の分離
凡例
制御の流れ
依存方向
アプリケーション
コード
データベース
オブジェクト
そのためには関係のコントラクト(契約・仕様・お約束)
のコンテキスト(文脈)を制御する
<<具象概念>> <<具象概念>>
コントラクト
<<抽象概念>>
それぞれの具象概念は抽象的な契約(仕様)に依存する Slide 68
契約の文脈をコントロールする
アプリケーション
コード
<<具象概念>>
コントラクト
<<抽象概念>>
データベース
オブジェクト
<<具象概念>>
Slide 69
アプリケーション
コード
<<具象概念>>
コントラクト
<<抽象概念>>
データベース
オブジェクト
<<具象概念>>
凡例
制御の流れ
依存方向
文脈
-The architecture rules are the same! -
Copyright 2019 @nuits_jp Slide 70
システム
サブシステム
コンポーネント
ソフトウェアのフラクタル
Copyright 2018 @nuits_jp Slide 71
クラス
サブシステム
クラス
コンポーネント
クラス クラス
ソフトウェア エンティティすべてに、ここまでの話は適用可能
• 要素間のインターフェースの文脈により、制御の流れと依存関係は制御可能
• 依存関係によって、安定性と柔軟性をコントロール可能
ソ
フ
ト
ウ
ェ
ア
エ
ン
テ
ィ
テ
ィ
ソフトウェア エンティティ 代表的なコントラクト
システム OpenAPI(なんならCSVのFTP転送)
サブシステム OpenAPIやSwagger
コンポーネント プログラム インターフェース
クラス プログラム インターフェース
ソフトウェア エンティティとコントラクト
Copyright 2018 @nuits_jp Slide 72
文脈によって、制御の流れと依存方向は分離し制御せよ
クライアント
エンティティ
<<具象概念>>
コントラクト
<<抽象概念>>
サーバー
エンティティ
<<具象概念>>
Slide 73
クライアント
エンティティ
<<具象概念>>
コントラクト
<<抽象概念>>
サーバー
エンティティ
<<具象概念>>
-The architecture rules are the same! -
Copyright 2019 @nuits_jp Slide 74
Easiest Clean Architecture
まとめ
まとめ
Slide 76Copyright 2019 @nuits_jp
• Clean Architectureとは、どんなソフトウェアにも適用可能な普遍的な
アーキテクチャである
• Clean Architectureは、次のふたつを誤解されがち
• 参考図の通りに関心を分離するのがClean Architectureである
• PresentationとModelの境界はInputとOutputを分離すべし
• 次のふたつを理解せずClean Architectureは語れない
• 依存性は、より上位レベルの方針にのみ向けよ
• 制御の流れと依存方向は分離し制御せよ
ThankYou!
Any Questions?

More Related Content

What's hot

例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
Takuto Wada
 
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツオブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ増田 亨
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
 
こわくない Git
こわくない Gitこわくない Git
こわくない Git
Kota Saito
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
 
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
 
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
 
Pythonによる黒魔術入門
Pythonによる黒魔術入門Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
 
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
 
メタプログラミングって何だろう
メタプログラミングって何だろうメタプログラミングって何だろう
メタプログラミングって何だろうKota Mizushima
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
Yoshitaka Kawashima
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
 
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装までドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
 

What's hot (20)

例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツオブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
こわくない Git
こわくない Gitこわくない Git
こわくない Git
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
DockerコンテナでGitを使う
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
 
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
 
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
 
Pythonによる黒魔術入門
Pythonによる黒魔術入門Pythonによる黒魔術入門
Pythonによる黒魔術入門
 
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
 
メタプログラミングって何だろう
メタプログラミングって何だろうメタプログラミングって何だろう
メタプログラミングって何だろう
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装までドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
 

Similar to 世界一わかりやすいClean Architecture

世界一わかりやすいClean Architecture release-preview
世界一わかりやすいClean Architecture release-preview世界一わかりやすいClean Architecture release-preview
世界一わかりやすいClean Architecture release-preview
Atsushi Nakamura
 
世界一わかりやすいClean Architecture - DroidKaigiバージョン
世界一わかりやすいClean Architecture - DroidKaigiバージョン世界一わかりやすいClean Architecture - DroidKaigiバージョン
世界一わかりやすいClean Architecture - DroidKaigiバージョン
Atsushi Nakamura
 
Desktop app dev strategy for .net core 3.0
Desktop app dev strategy for .net core 3.0Desktop app dev strategy for .net core 3.0
Desktop app dev strategy for .net core 3.0
Atsushi Nakamura
 
C#メタプログラミング概略 in 2021
C#メタプログラミング概略 in 2021C#メタプログラミング概略 in 2021
C#メタプログラミング概略 in 2021
Atsushi Nakamura
 
パターンでわかる! .NET Coreの非同期処理
パターンでわかる! .NET Coreの非同期処理パターンでわかる! .NET Coreの非同期処理
パターンでわかる! .NET Coreの非同期処理
Kouji Matsui
 
α版 継続的にテスト可能な設計を考える
α版 継続的にテスト可能な設計を考えるα版 継続的にテスト可能な設計を考える
α版 継続的にテスト可能な設計を考える
Atsushi Nakamura
 
Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
Visual Studio 2019で始める「WPF on .NET Core 3.0」開発Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
Atsushi Nakamura
 
世界一わかりやすいClean Architecture alpha-1
世界一わかりやすいClean Architecture alpha-1世界一わかりやすいClean Architecture alpha-1
世界一わかりやすいClean Architecture alpha-1
Atsushi Nakamura
 
201110 03
201110 03201110 03
201110 03
openrtm
 
LightSwitch 結局何ができるの
LightSwitch 結局何ができるのLightSwitch 結局何ができるの
LightSwitch 結局何ができるの
Yoshitaka Seo
 
参加したセッションの ピックアップ
参加したセッションのピックアップ参加したセッションのピックアップ
参加したセッションの ピックアップ
健一 辰濱
 
Netmf-180224
Netmf-180224Netmf-180224
Netmf-180224
Atomu Hidaka
 
継続的にテスト可能な設計を考える
継続的にテスト可能な設計を考える継続的にテスト可能な設計を考える
継続的にテスト可能な設計を考える
Atsushi Nakamura
 
3.RTCプログラミング演習
3.RTCプログラミング演習3.RTCプログラミング演習
3.RTCプログラミング演習
openrtm
 
最近のQ#について
最近のQ#について最近のQ#について
最近のQ#について
Takayoshi Tanaka
 
センパイ!このプログラムクラッシュするんですけど。。。
センパイ!このプログラムクラッシュするんですけど。。。センパイ!このプログラムクラッシュするんですけど。。。
センパイ!このプログラムクラッシュするんですけど。。。
yjono Seino
 

Similar to 世界一わかりやすいClean Architecture (16)

世界一わかりやすいClean Architecture release-preview
世界一わかりやすいClean Architecture release-preview世界一わかりやすいClean Architecture release-preview
世界一わかりやすいClean Architecture release-preview
 
世界一わかりやすいClean Architecture - DroidKaigiバージョン
世界一わかりやすいClean Architecture - DroidKaigiバージョン世界一わかりやすいClean Architecture - DroidKaigiバージョン
世界一わかりやすいClean Architecture - DroidKaigiバージョン
 
Desktop app dev strategy for .net core 3.0
Desktop app dev strategy for .net core 3.0Desktop app dev strategy for .net core 3.0
Desktop app dev strategy for .net core 3.0
 
C#メタプログラミング概略 in 2021
C#メタプログラミング概略 in 2021C#メタプログラミング概略 in 2021
C#メタプログラミング概略 in 2021
 
パターンでわかる! .NET Coreの非同期処理
パターンでわかる! .NET Coreの非同期処理パターンでわかる! .NET Coreの非同期処理
パターンでわかる! .NET Coreの非同期処理
 
α版 継続的にテスト可能な設計を考える
α版 継続的にテスト可能な設計を考えるα版 継続的にテスト可能な設計を考える
α版 継続的にテスト可能な設計を考える
 
Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
Visual Studio 2019で始める「WPF on .NET Core 3.0」開発Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
 
世界一わかりやすいClean Architecture alpha-1
世界一わかりやすいClean Architecture alpha-1世界一わかりやすいClean Architecture alpha-1
世界一わかりやすいClean Architecture alpha-1
 
201110 03
201110 03201110 03
201110 03
 
LightSwitch 結局何ができるの
LightSwitch 結局何ができるのLightSwitch 結局何ができるの
LightSwitch 結局何ができるの
 
参加したセッションの ピックアップ
参加したセッションのピックアップ参加したセッションのピックアップ
参加したセッションの ピックアップ
 
Netmf-180224
Netmf-180224Netmf-180224
Netmf-180224
 
継続的にテスト可能な設計を考える
継続的にテスト可能な設計を考える継続的にテスト可能な設計を考える
継続的にテスト可能な設計を考える
 
3.RTCプログラミング演習
3.RTCプログラミング演習3.RTCプログラミング演習
3.RTCプログラミング演習
 
最近のQ#について
最近のQ#について最近のQ#について
最近のQ#について
 
センパイ!このプログラムクラッシュするんですけど。。。
センパイ!このプログラムクラッシュするんですけど。。。センパイ!このプログラムクラッシュするんですけど。。。
センパイ!このプログラムクラッシュするんですけど。。。
 

More from Atsushi Nakamura

Settings SyncとCodespaceで体験する新世代へのパラダイムシフト
Settings SyncとCodespaceで体験する新世代へのパラダイムシフトSettings SyncとCodespaceで体験する新世代へのパラダイムシフト
Settings SyncとCodespaceで体験する新世代へのパラダイムシフト
Atsushi Nakamura
 
Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖
Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖
Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖
Atsushi Nakamura
 
継続的にテスト可能な設計を考える ベータ版
継続的にテスト可能な設計を考える ベータ版継続的にテスト可能な設計を考える ベータ版
継続的にテスト可能な設計を考える ベータ版
Atsushi Nakamura
 
App center analyticsを使い倒そう
App center analyticsを使い倒そうApp center analyticsを使い倒そう
App center analyticsを使い倒そう
Atsushi Nakamura
 
Old:App center analyticsを使い倒そう
Old:App center analyticsを使い倒そうOld:App center analyticsを使い倒そう
Old:App center analyticsを使い倒そう
Atsushi Nakamura
 
Xamarin.forms navigation overview
Xamarin.forms navigation overviewXamarin.forms navigation overview
Xamarin.forms navigation overview
Atsushi Nakamura
 
App center analyticsを使い倒そう
App center analyticsを使い倒そうApp center analyticsを使い倒そう
App center analyticsを使い倒そう
Atsushi Nakamura
 
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
Atsushi Nakamura
 
Blue monkey architecture overview
Blue monkey architecture overviewBlue monkey architecture overview
Blue monkey architecture overview
Atsushi Nakamura
 
Xamarin Dev days 2 xamarin.forms ja
Xamarin Dev days 2   xamarin.forms jaXamarin Dev days 2   xamarin.forms ja
Xamarin Dev days 2 xamarin.forms ja
Atsushi Nakamura
 
Why prism for xamarin.forms
Why prism for xamarin.formsWhy prism for xamarin.forms
Why prism for xamarin.forms
Atsushi Nakamura
 
Enterpriseから見たXamarinの可能性
Enterpriseから見たXamarinの可能性Enterpriseから見たXamarinの可能性
Enterpriseから見たXamarinの可能性
Atsushi Nakamura
 

More from Atsushi Nakamura (12)

Settings SyncとCodespaceで体験する新世代へのパラダイムシフト
Settings SyncとCodespaceで体験する新世代へのパラダイムシフトSettings SyncとCodespaceで体験する新世代へのパラダイムシフト
Settings SyncとCodespaceで体験する新世代へのパラダイムシフト
 
Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖
Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖
Unicodeで半角全角を扱うAmbiguous(曖昧さ)とUncertainty(不確実性)の恐怖
 
継続的にテスト可能な設計を考える ベータ版
継続的にテスト可能な設計を考える ベータ版継続的にテスト可能な設計を考える ベータ版
継続的にテスト可能な設計を考える ベータ版
 
App center analyticsを使い倒そう
App center analyticsを使い倒そうApp center analyticsを使い倒そう
App center analyticsを使い倒そう
 
Old:App center analyticsを使い倒そう
Old:App center analyticsを使い倒そうOld:App center analyticsを使い倒そう
Old:App center analyticsを使い倒そう
 
Xamarin.forms navigation overview
Xamarin.forms navigation overviewXamarin.forms navigation overview
Xamarin.forms navigation overview
 
App center analyticsを使い倒そう
App center analyticsを使い倒そうApp center analyticsを使い倒そう
App center analyticsを使い倒そう
 
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら「関心の分離」と「疎結合」   ソフトウェアアーキテクチャのひとかけら
「関心の分離」と「疎結合」 ソフトウェアアーキテクチャのひとかけら
 
Blue monkey architecture overview
Blue monkey architecture overviewBlue monkey architecture overview
Blue monkey architecture overview
 
Xamarin Dev days 2 xamarin.forms ja
Xamarin Dev days 2   xamarin.forms jaXamarin Dev days 2   xamarin.forms ja
Xamarin Dev days 2 xamarin.forms ja
 
Why prism for xamarin.forms
Why prism for xamarin.formsWhy prism for xamarin.forms
Why prism for xamarin.forms
 
Enterpriseから見たXamarinの可能性
Enterpriseから見たXamarinの可能性Enterpriseから見たXamarinの可能性
Enterpriseから見たXamarinの可能性
 

世界一わかりやすいClean Architecture

Editor's Notes

  1. こんにちは。 それでは早速はじめさせていただきます。 本日は 「世界一わかりやすいClean Architecture ~ 誤解されがちな二つのことと、おさえるべき二つのこと ~」 というタイトルでお話しさせていただきます。 ちょっとマサカリ投げ放題みたいな内容なんですけど、皆さんくれぐれもお手柔らかにお願いします。
  2. さて、本題に入る前にふたつ質問させてください
  3. あまりに有名な図ですが、この図を見たことあるかた 良かったら挙手していただけますか?
  4. じゃぁもう一つ、この書籍読破したよって方挙手していただけますか? 読んでいない方、掛け値なしの名著だと思うのでまだ読まれていない方は、今すぐ購入して読みましょう。 個人的には
  5. というわけで、本セッションの目指すところでが
  6. 今日は、この場にいる皆さんが 「クリーンアーキテクチャチョットデキル」 という状態になっていただくことを目指します。 ちょっと自信ない方は今のうちにご退席ください。嘘です。
  7. というわけで、本セッションの概要ですが
  8. クリーンアーキテクチャについて、おもに次のふたつの事をお話しさせていただきます。 ひとつは、クリーンアーキテクチャの誤解されがちな二つのことに対する解説。 もうひとつは、私がクリーンアーキテクチャについて、本当に重要だと考えているふたつの事について、お話しします。
  9. さて本題に入る前に、少し注意事項があります。
  10. 今回お話しするのは、あくまで私の解釈です。 特に極端に要約しているので、今日お話しすることがすべてではないことはご理解ください。 また、書籍の記載とやや異なる説明もします。 それでも私は著者が本当に言いたかったこと、クリーンアーキテクチャでもっとも大切なことは今日お話しする二点にあると考えています。
  11. なお異論・反論は大歓迎です。 オンラインでご意見をいただいても良いですし、この後直接お話しさせていただくのも歓迎です。 寝不足なので、その辺で死亡してなかったらですがw ぜひ議論してさせていただけると嬉しいです。
  12. 本題に入る前に最後にひとつ。 簡単に自己紹介させてください。
  13. 中村充志と申します。 リコージャパンのソリューション開発部ってところで、主に金融機関向けの 受託開発でアーキテクトをやってます。 「持続可能なソフトウェア」というテーマで色々考えるのが最近の趣味です。 今年の目標の一つは今日でクリアしましたので、あとはテストのハンズオン開催ができると良いなと思ってます。 では、本題に入りましょう。
  14. まずは「誤解されがちな二つのこと」です。
  15. この図をご覧になったことのある方は多いんじゃないかと思います。
  16. 実はこの図が良くできてい過ぎることが、大きな誤解を招く要因になっていると私は考えています。 どういうことでしょうか?
  17. ひとつは、この図は決してソフトウェアの関心を ControllerやUseCase、Entityに分離しろという意味でもなく レイヤーをこの4つに分割しろという意味ではないということです
  18. そしてふたつ目は右下のこれです。 これもPresentationを古典的なMVCのように設計しろという意味ではないですし データや処理の流れを一方通行にしろと言っている訳でもありません。
  19. では、どういう意味でしょうか?先の図で本当に大切なことは
  20. 依存性は、外から中だけに向かっていなくてはいけない。 というたった一点にあります。 でもじゃぁ、例えばEntitiesの状態が変わったことで、UIを受動的に変化させたいみたいな 中から外を呼ばなければいけないときはどうすれば良いの? という疑問が、すぐに湧いてきますよね?
  21. 右下の図は、内側の変化に応じて外側を呼び出したい場合に 依存性は外から中に向けたまま、処理の流れとして中から外に戻すにはどうすればよいのか? を例示しているものです。
  22. そんなこと言っても、本当にあってるのか?って今皆さん思いましたよね?
  23. はい。もちろん根拠あっての話です。 そもそも著者は書籍の先頭でこう明言しています。
  24. 「アーキテクチャのルールはどれも同じである!」 日本語版では帯にも書かれていますよね。
  25. つまり、本当にすべてのソフトウェアが同一のアーキテクチャに帰結するとすれば ・レイヤーが4つ限定であったり ・UIがMVC的でMVVMなどを否定していたり ・そもそもWeb限定だったり ・中から外の呼び出しがApplicationレイヤーとInterface Adapterレイヤーの間だけで発生するわけがないですし ・中央がEntitiesじゃなくちゃだめで、DDDするななんて そんな分けないですよね?
  26. 書籍を読めば、ちゃんと先の図があくまで例示であると書かれています。 もともとクリーンアーキテクチャの発表前は、ヘキサゴナルアーキテクチャとかオニオンアーキテクチャが広く共有されていました。 そしてそれらのアーキテクチャには類似の共通点があることも知られていました。 そしてクリーンアーキテクチャの解説には、それらの著名なアーキテクチャは、先ほどの図のように記述することで単一のアイディアに統合することを例示するために書かれた図なんです。 そう
  27. クリーンアーキテクチャというのは、どんなソフトウェアにも適用可能な普遍的なアーキテクチャなんです。 あえて言うと、クリーンアーキテクチャを採用しないという選択肢は、基本的には「あくまで基本的には」無いといって差し支えありません。
  28. では先の図のように実装することがクリーンアーキテクチャではないとしたら クリーンアーキテクチャについて何を抑えたらよいのでしょうか? 私はつぎのふたつこそ、本質的に重要なことだと考えています。
  29. ひとつめは先ほども話しました。 ソフトウェアは、より上位レベルの方針にのみ依存せよということ
  30. ふたつ目は ひとつめを実現するために、依存性を制御の流れから分離してコントロールするということです。
  31. てことで、ここからは具体例を見ながら解説したいと思います。
  32. 今回はSQL ServerのサンプルDBであるAdventure Worksを利用します。 こちらにER図がありますが、これらのテーブルからプロダクト別の総売り上げをCSVに出力するコンソールアプリを作ります。
  33. アーキテクチャはもちろんクリーンアーキテクチャです。
  34. では早速コードを見てみましょう!
  35. さて、先ほどのコードをモデル化したのがこちらになります。 全体的にそう悪くないようにも見えるんですが、少なくとも二つは問題があります。 ひとつは、ぱっと見から分かりますね。
  36. この部分でUsecaseからPresenterに依存関係ができてしまっています。
  37. 依存関係はPresentaerからUsecaseである必要があります。
  38. でも逆になっちゃっていますね。
  39. という訳で修正してみましょう。
  40. さて、これでクリーンアーキテクチャになったでしょうか? 先ほどのモデルで見直してみましょう。
  41. IPerenterが移動したことで依存方向がPresenterからUseCaseに移動しました。
  42. ちゃんと右下の図の通りになりましたね。 処理の流れは一方通行で、でもすべての依存は外から中に向いています。
  43. ただ厳密にいうとまだ中から外へ依存が向かっている箇所があります。 どこか?
  44. ここです。 Gatewayがデータベースに依存しています。
  45. GatewayはDatabaseに依存するという選択肢はもちろんありだと考えているのですが
  46. まぁ今回はせっかくなので、ここもDBからGatewayに依存するようにしてみたいと思います。
  47. でもGatewayはDBを呼び出さないといけないし DB操作にはSQLが必要ですよね? GatewayがDBに依存しないなんて実現可能なのでしょうか? 勿論可能ですがちょっと意味が異なります。
  48. もちろんSQLを利用しないという意味ではないですし RDBというアーキテクチャに依存しないという意味ではないです システム固有の永続かされたデータのスキーマに依存しないという意味です
  49. この部分を見てください。 Repositoryの実装ではProductテーブルとSalesOrderDetailに対応する クラスを作ってDBアクセスし、Repositoryの中でProductSalesインスタンスを 生成していましたよね? これらのクラスをよく見てみましょう。
  50. 現在の実装は、リポジトリが完全にデータベースの文脈で記述されているのが見て取れます。 結構な列数がありますよね。
  51. しかし今回は、この4項目しか本来は必要ありません。
  52. テーブル構造にダイレクトに依存してしまうと、テーブル変更の影響をダイレクトに受けてしまいます。 他の機能の影響で列が増えて、実際にはほぼ影響がないのに回帰テストをしないといけない。 みたいな事に陥ったことはありませんか?
  53. そこでここの依存関係がDBからGatewayに向いていれば 少なくともGatewayには影響がないことが担保できます。 では実際にはどうするか?
  54. 制御の流れと依存方向は分離することで、コントロールできます。
  55. 大切なのは文脈です
  56. GatewayがDBへ依存しているというのはつまり Gatewayのクラス設計がDBのスキーマに依存していることを指しているのです
  57. そうではなく、DBがGatewayの文脈で定義されていればよいという事になります。 とは言え、これらのテーブルは別にこの機能のためだけにある訳じゃありませんよね。 ではどうすれば良いのか?
  58. 最も一般的な回答は、CQRSを使いましょうという事になります。
  59. CQRSとは、端的にいうとデータベース操作を更新と参照に 責務を分離しなさいという方法論のことで 今回はQueryに該当します。 つまりGatewayの文脈に合わせたQuery用のオブジェクトをDB側に用意すればよいということになります。
  60. ただCQRSを完ぺきに適用しようというのは簡単じゃないです。 特に既存のシステムに組み込むには多大な努力が必要になりますし、そこまでしてもケースによってはやりすぎになってしまいます。 そこで、今回はDBのビューを使った手軽な方法を詳解したいと思います。
  61. ではサンプルコードを見てみましょう。
  62. 結果的にこうなりました。 DBにはEntityのPdoructSalesの文脈に適用したViewを作成して、Repositoryからはそれを参照します。 こうすることで、DBつまり外から中に依存するように文脈が書き換えられました。
  63. 完ぺきにこのアーキテクチャを実現していますね! さて、あらためて整理しましょう。
  64. なおCQRSと類似したものにCQSという概念があります。 CQRSはデータベースに対するパターンだったのに対して CQSはクラス、つまりコードにたいするパターンです。 DBの文脈をGatewayで吸収する選択をする場合は CQSも検討してみると良いかもしれません。
  65. さてあらためて 大切なのはやはり制御の流れから依存関係を分離することにあります。
  66. 一般的に依存方向は制御の流れに引っ張られがちです。
  67. しかし、これらは分離してコントロールすることが可能です。
  68. そのためには二つの依存関係の間のコントラクト、つまり契約・仕様・お約束を文脈によって制御する必要があります。 抽象的なコントラクトを導出することで、それぞれの具象概念はどちらも、抽象概念であるコントラクトに依存することになります。
  69. そしてこのコントラクトをどちらの文脈で定義するかによって 具象概念間の依存関係を自由にコントロールすることができるようになります。
  70. 「アーキテクチャのルールはどれも同じである」 という真意が何となく伝わってきたでしょうか?
  71. そもそもソフトウェアは良くフラクタルのようだと言われていますよね。 ①クラスとクラスがまとまってコンポーネントとなり ②コンポーネントとコンポーネントがまとまってサブシステムになります。そして ③サブシステムとサブシステムがまとまってシステムになります。 ④ここではクラス・コンポーネント・サブシステム・システムを、ソフトウェア エンティティと呼ぶことにします。 ⑤ソフトウェアエンティティのすべてにおいて、ここまでした話の内容は適用できます。 もちろんサブシステム間は例えばWeb APIになったりするでしょうけど どの要素間であっても、コントラクトの文脈を管理する事で 制御の流れと依存関係は制御することが可能です。
  72. こちらに各ソフトウェアエンティティごとの代表劇なコントラクトを上げてみました。 なんならシステム間でのやり取りがCSVとか固定長テキストであっても、そのファイルがどっちのシステムの文脈によってるかによって、システム間の依存関係はコントロールできるわけです。
  73. 文脈によって、制御の流れと依存方向は分離し制御することが可能です。
  74. クリーンアーキテクチャがあらゆるソフトウェアにおいて 「アーキテクチャのルールはどれも同じである」 ことを受け入れていただけましたか?
  75. とうわけで、今日のお話は終わりになります。 最後に簡単にまとめましょう。
  76. ①クリーンアーキテクチャは、どんなソフトウェアにも適用可能な普遍的なアーキテクチャです ②クリーンアーキテクチャの代表的な図は、誤解されがちです ③クリーンアーキテクチャの本質的で本当に大切なことが二つはあって ひとつは 依存性はより上位レベルの方針、つまりオニオンアーキテクチャであれば外から中にだけ依存するべきであること そしてもう一つは 制御の流れと依存方向は分離してコントロールできるということです
  77. という訳で、本日の内容は以上になります。 ご清聴ありがとうございました。