Object-Oriented Conference 2020（https://ooc.dev/） の登壇資料
プロポーザル https://fortee.jp/object-oriented-conference-2020/proposal/dedc65ee-8858-4eaa-aa47-4c1f1fbe4439
当日のタイムライン https://twitter.com/search?q=since%3A2020-02-16_16%3A30%3A00_JST%20until%3A2020-02-16_16%3A51%3A00_JST%20%23ooc_e%20-from%3Aakiray03
登壇レポートブログ https://tech-blog.rakus.co.jp/entry/20200313/it-event
ドメイン駆動設計を支えるアーキテクチャテストObject-Oriented Conference 2020@kawanamiyuu
View Slide
2https://speakerdeck.com/kawanamiyuu/jjug-ccc-2019-springアーキテクチャテストへのモチベーション、具体例を紹介した入門編
自己紹介● かわなみゆう● @kawanamiyuu● 株式会社ラクス / Lead Engineer● HR x SaaS の開発● Java (Spring Boot, Doma) / Vue.js / Puppeteer● 自動テスト（が書きやすい設計を考えながらコード） を書くのがすき3
Context Map4https://www.infoq.com/articles/ddd-contextmapping/
Context Map5https://www.infoq.com/articles/ddd-contextmapping/
Layer Architecture（〇〇〇〇を逆転したレイヤードアーキテクチャ） 6（一般的なレイヤードアーキテクチャ）
Layer Architecture（〇〇〇〇を逆転したレイヤードアーキテクチャ） 7（一般的なレイヤードアーキテクチャ）
Clean Architecture8
Clean Architecture9
Domain ModelEmployeeProcedureReportxxxyyy10
依存関係11
アーキテクチャとは「依存関係」のガイドライン12
アーキテクチャの正体● アーキテクチャとはソフトウェアの構造についての取り決めであり、● 解像度を上げていくと、ソフトウェアを構成する責務や関心事の「依存関係」についての取り決め13
アーキテクチャの視座● 責務や関心事の粒度○ 大きな粒度：コンテキスト、レイヤー○ 小さな粒度：パッケージ、クラス● それぞれの粒度で依存関係を注意深く設計する14
アーキテクチャとオブジェクト指向設計原則● （乱暴に言うと）Layer Architecture も Clean Architectureも 、DDD のような設計論も、依存関係を適切に設計したいだけ● その礎としてのオブジェクト指向設計原則○ 単一責任の原則（SRP）○ 依存関係逆転の原則（DIP）15
「アーキテクチャ」の問題点16
「ガイドライン」というものの性質● ガイドラインとは「指針」「ルール」「マナー」● 人が決めて、守る（守らせる）● 最初にルールをつくるのは、簡単● ルール通りつくり始めるのも、簡単17
「ガイドライン」というものの性質● ガイドラインとは「指針」「ルール」「マナー」● 人が決めて、守る（守らせる）● 最初にルールをつくるのは、簡単● ルール通りつくり始めるのも、簡単 なにが難しいのか？18
アーキテクチャの維持が難しい19
アーキテクチャの維持は難しい人が決めたことであるがゆえに、壊れやすい。時間が経つと「大きな泥団子（Big Ball of Mud）」に。● よくある要因○ 設計知識の属人化・暗黙知化○ 開発スキルのばらつき○ 納期優先、相次ぐメンバー増員20
どうすればよいか？21
22アーキテクチャをテストしたい
23https://www.archunit.org/
ArchUnit● GitHub○ https://github.com/TNG/ArchUnit○ https://github.com/TNG/ArchUnit-Examples● Twitter○ https://twitter.com/archtests● Technology Radar○ https://www.thoughtworks.com/radar/tools/archunit○ 進化的アーキテクチャ x 適応度関数24
ArchUnit を一言でいうと● Java（や Kotlin, Scala）で書かれたアプリケーションのパッケージやクラスの依存関係を JUnit のテストコードとして表現し、テストできるテストフレームワーク● 依存関係の他にも、そのアプリケーション固有の実装ルールもテストすることができる25
他のプログラミング言語でのアーキテクチャテスト● TNG/ArchUnitNET（C#）● iternity/archlint.cs（C#）● BenMorris/NetArchTest（.Net）● sensiolabs-de/deptrac（PHP）● carlosas/phpat（PHP）● nazonohito51/dependency-analyzer（PHP）26
アーキテクチャテストの例27
28@Testvoid DIP_依存性逆転の原則_を適用したレイヤードアーキテクチャ () {layeredArchitecture().layer("ui").definedBy("com.example.presentation..").layer("app").definedBy("com.example.application..").layer("domain").definedBy("com.example.domain..").layer("infra").definedBy("com.example.infrastructure..").whereLayer("ui").mayOnlyBeAccessedByLayers("infra").whereLayer("app").mayOnlyBeAccessedByLayers("infra", "ui").whereLayer("domain").mayOnlyBeAccessedByLayers("infra", "app").whereLayer("infra").mayNotBeAccessedByAnyLayer().check(CLASSES);}
29@Testvoid DIP_依存性逆転の原則_を適用したレイヤードアーキテクチャ () {layeredArchitecture().layer("ui").definedBy("com.example.presentation..").layer("app").definedBy("com.example.application..").layer("domain").definedBy("com.example.domain..").layer("infra").definedBy("com.example.infrastructure..").whereLayer("ui").mayOnlyBeAccessedByLayers("infra").whereLayer("app").mayOnlyBeAccessedByLayers("infra", "ui").whereLayer("domain").mayOnlyBeAccessedByLayers("infra", "app").whereLayer("infra").mayNotBeAccessedByAnyLayer().check(CLASSES);}
30@Testvoid ReportドメインはProcedureドメインからのみ依存される () {classes().that().resideInAPackage("com.example.domain.report..").should().onlyBeAccessed().byAnyPackage("com.example.domain.procedure..").check(CLASSES);}
31@Testvoid ReportドメインはProcedureドメインからのみ依存される () {classes().that().resideInAPackage("com.example.domain.report..").should().onlyBeAccessed().byAnyPackage("com.example.domain.procedure..").check(CLASSES);}
32@Testvoid ドメイン層はWeb実行環境に依存しない () {noClasses().that().resideInAPackage("com.example.domain..").should().dependOnClassesThat().resideInAPackage("javax.servlet..").check(CLASSES);}@Testvoid ドメイン層はWebアプリケーションフレームワークに依存しない () {noClasses().that().resideInAPackage("com.example.domain..").should().dependOnClassesThat().resideInAPackage("org.springframework..").check(CLASSES);}
33@Testvoid ドメイン層はWeb実行環境に依存しない () {noClasses().that().resideInAPackage("com.example.domain..").should().dependOnClassesThat().resideInAPackage("javax.servlet..").check(CLASSES);}@Testvoid ドメイン層はWebアプリケーションフレームワークに依存しない () {noClasses().that().resideInAPackage("com.example.domain..").should().dependOnClassesThat().resideInAPackage("org.springframework..").check(CLASSES);}
ドメイン駆動設計にとってのアーキテクチャテスト34
ドメインが隔離されていることを担保する● ドメインと、他の詳細や関心との依存関係○ ドメインと技術的詳細○ ドメインと UI● ドメイン同士の依存関係これらが期待通りであることを自動テストによって担保し続けることができる。35
アーキテクチャテストの失敗は悪か？● アーキテクチャテストはあるべき依存関係を表現したもの● アーキテクチャテストは失敗しないはずのテスト● アーキテクチャテストが失敗するとき○ 実装誤り○ ○36
アーキテクチャテストの失敗は悪か？● アーキテクチャテストはあるべき依存関係を表現したもの● アーキテクチャテストは失敗しないはずのテスト● アーキテクチャテストが失敗するとき○ 実装誤り○ アーキテクチャに対する発見のサイン○ アーキテクチャについて議論する始点37
ドメイン駆動設計が支えるアーキテクチャ● ドメイン駆動設計の真髄は、設計⇔実装のフィードバックループ● 実装で得た知識が設計にも反映される38
ドメイン駆動設計が支えるアーキテクチャ● ドメイン駆動設計の真髄は、設計⇔実装のフィードバックループ● 実装で得た知識が設計にも反映される● アーキテクチャも同じ● アーキテクチャも一度決めて終わりではない● アーキテクチャもシステムの成長とともに磨かれる39
アーキテクチャの目的40
41
この図は● モノリシックなアプリケーション内部の、ドメイン同士の依存関係？● マイクロサービスアーキテクチャで実現されたアプリケーションの、サービス同士の依存関係？42
この図は● モノリシックなアプリケーション内部の、ドメイン同士の依存関係？● マイクロサービスアーキテクチャで実現されたアプリケーションの、サービス同士の依存関係？どちらもありえる。43
ドメイン駆動設計という文脈で私たちが「ドメイン」と呼んでいるものが、ありていに言えば、高凝集で疎結合な実装技術によって実現されていれば、システムとしてもビジネスとしても多くの選択肢が残される。モノリスからマイクロサービスへ、アーキテクチャを進化させる可能性も。44
ソフトウェアが「ソフト」であるための選択肢を残す。それがアーキテクチャ。そのアーキテクチャが意図する依存関係を維持し、ソフトウェアの発展の可能性を支えるアーキテクチャテスト。45
Appendix.46
参考資料● Books○ エリック・エヴァンスのドメイン駆動設計（ Eric Evans）○ Clean Architecture ―達人に学ぶソフトウェアの構造と設計（ Robert C.Martin）○ 進化的アーキテクチャ ―絶え間ない変化を支える（ Neal Ford, Rebecca Parsons, Patrick Kua）● Talk○ JJUG CCC 2019 Spring■ ArchUnit で Java / Kotlin アプリケーションのアーキテクチャを CI する■ https://speakerdeck.com/kawanamiyuu/jjug-ccc-2019-spring● Blog○ ドメイン駆動設計#1 Advent Calendar 2019■ 6日目：ドメイン駆動設計を支えるアーキテクチャテスト■ https://tech-blog.rakus.co.jp/entry/20191206/java 47
kawanamiyuu
kubukoz
oogfranz
smt7174
oekazuma
mizunohiroaki
tatematsu_san
dskst
hirosatogamo
konboi
jkebertz
iseki
shimashima35
roundedbygravity
addyosmani
jennybc
jensimmons
paigeccino
carmenintech
sonatard
bluesmoon
jonyablonski
brettharned
myddelton
lynnandtonic