Goとクリーンアーキテクチャ DMM.go#2

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 2020 EXNOA LLC クリーンアーキテクチャは何を示すのか(3/4) ● 具体的なアーキテクチャとの関係 ○ レイヤード ○ ヘキサゴナル ○ オニオン ○ etc. これらのアーキテクチャはどれも細部は異なるけれども、とてもよく似ている。これらはいずれも同じ目的を持っている。関心の分離だ。これらはいずれも、ソフトウェアをレイヤーに分けることによって、関心の分離を達成する。 12 クリーンアーキテクチャ(The Clean Architecture翻訳)

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2020 EXNOA LLC 関心の分離によって得られるもの(1/2) ● フレームワーク独立 ○ フルスタックなフレームワークを必要としないし、依存しない ● テスト可能 ○ 単に可能ではなく、外部要素に囚われずにテストができる ● UI独立 ○ ビジネスルールの変更なしにUIを置き換えられる ● データベース独立 ○ データベースを容易に交換することができる ● 外部機能独立 ○ ビジネスルールは外側について何も知らなくていい 14 クリーンアーキテクチャ(The Clean Architecture翻訳)

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2020 EXNOA LLC Goとクリーンアーキテクチャ ● クリーンアーキテクチャは特定の技術に依らない ○ 特定のプログラミング言語に依存することはない ● フレームワークの選び方は気をつける必要がある ○ フレームワーク独立の思想に反するので ○ フルスタックのフレームワークとはあまり馴染まなそう ● Goは基本的に標準パッケージで事足りるようにするという思想 ○ フレームワークとして提供されるものも薄いものが多い ○ クリーンアーキテクチャと親和性が高い（ちなみにGoを選択した理由はこれだけじゃないのですが話が散らかるので割愛） 17

Slide 18

Slide 18 text

© 2020 EXNOA LLC ディレクトリ構成例 18 application/ ├── entities │ └── employee.go ├── infrastructure │ ├── config.go │ ├── router.go │ └── sqlhandler.go ├── interfaces │ ├── employee_controller.go │ ├── employee_controller_test.go │ ├── employee_output.go │ ├── employee_repository.go │ └── sqlhandler.go ├── main.go └── usecases ├── employee_interactor.go ├── employee_repository.go └── mocks └── EmployeeRepository.go ● GoはPackage内Private ○ entities ○ usecases ○ interfaces ○ infrastructure ● 1リポジトリの中に複数のサブドメインがある場合 ○ applicationの下に1つ階層を作る ○ もしくはリポジトリを分ける

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2020 EXNOA LLC Goを使った開発 ● 言語として提供されるフォーマット ○ 複数人開発で、書き方での差分が出ないのでとても良い ● 言語として提供されるパッケージ管理 ○ Go Modules 便利 ● 後方互換性の高さ ○ ちゃんと互換性を持ったマイナーバージョンアップ ● 学習コストの低さ ○ Go自体を覚えるのはそう難しくない（と思う） ○ 難しいのは設計やアーキテクチャ、ドメイン分析… 22

Slide 23

Slide 23 text

© 2020 EXNOA LLC Goを使った開発 ● 激動の時代 ○ 多種多様なアーキテクチャから選定しないといけない場合が増えた ■ メリットを享受できないのにフルスタックなフレームワークを使うと困る ○ RDB以外にもいろんなDBが使える時代 ■ Amazon DynamoDB, Cloud Spanner, etc. ○ 分散システムが（つらいけど）手軽に利用できる時代 ■ Amazon Kinesis, Apache Kafka, etc. ○ フロントエンドとバックエンドの分離 ■ バックエンドは単に永続層からデータを取ってフロントにデータを渡すだけ弊社のビジネスの性質上、こういったものを利用しないといけない場合が増えてきた 23

Slide 24

Slide 24 text

© 2020 EXNOA LLC Goを使った開発 ● クリーンアーキテクチャとの相性 ○ 個人的には結構良いと思う ○ 薄いフレームワークを組み合わせるのに便利 ■ 失敗しても変えやすいし ● DIPよくわかってなかったことが露呈した ○ インターフェースをどう使うんだ？？？って最初はなっていた Go's purpose is therefore not to do research into programming language design; it is to improve the working environment for its designers and their coworkers. 24 Go at Google: Language Design in the Service of Software Engineering

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2020 EXNOA LLC まとめ(1/2) ● クリーンアーキテクチャは関心の分離を求める思想 ○ 具体的なアーキテクチャではないが、共通のルールとしての知恵 ■ 人類って万能の答えを欲しがるけど、それに価値はない ● クリーンアーキテクチャやったほうがいい？ ○ 多分この質問はおかしい ■ 関心を一切分離しなくていいシステムってなんだろ… ● フルスタックなフレームワークはダメなの？ ○ そんなことはない ■ MVCのフルスタックなフレームワークで価値を出せる時と場合はある ■ ぶっちゃけ便利だしね 26

Slide 27

Slide 27 text

© 2020 EXNOA LLC まとめ(2/2) ● 激動の時代に生まれたGo ○ クリーンアーキテクチャとの親和性 ○ クラウドネイティブな開発への親和性 ● アーキテクチャや設計原則、デザインパターンは人類の英知 ○ こうやるとやばかったからこうした or こうするとうまくいった ■ 必ず生まれた背景があるのでその把握がないと逆に操られる ○ 書籍：Clean Architectureにはエンジニアリングの歴史の話が出てきて、そういった背景が知れるのでオススメです ■ 逆に具体例をこの本に求めると悲しいことになります ○ DDDとオブジェクト指向についての知識の上に成り立っている感じはする 27 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (角征典高木正弘 Robert C. Martin)

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© 2020 EXNOA LLC 資料集 ● The Clean Architecture ○ そもそもの大本 ○ クリーンアーキテクチャ(The Clean Architecture翻訳) ● 世界一わかりやすいClean Architecture ○ 誤解されがな2点とおさえるべき2点 ● Dive to clean architecture with golang ○ 実装に挑戦してみたもの ■ https://github.com/bmf-san/go-clean-architecture-web-application-boilerplate ● クリーンアーキテクチャ完全に理解した ○ Clean Architectureに出てくる用語について、複数のソースから説明されている 30

Slide 31

Slide 31 text

© 2020 EXNOA LLC DDDの領域について 31 ● DDDには３つの領域があるという話 ○ 開発思想 ■ システムの複雑性に取り組むために、業務の専門家と技術の専門家で言語・モデルの認識を合わせ、継続的に進化させていこう、という考え方 ○ 戦略的設計 ■ ドメインモデリングの前提を揃えるための、モデリング対象を定義する原則と手法(コアドメイン /サブドメイン、境界付けられたコンテキスト、コンテキストマップ等) ○ 戦術的設計 ■ モデルを具体的に表現するためのパターン(エンティティ、レポジトリ、レイヤードアーキテクチャ等) なぜDDD初心者はググり出してすぐに心がくじけてしまうのか

Slide 32

Slide 32 text

© 2020 EXNOA LLC エンティティという言葉について（1/3） 32 以下、自分の考えです ● DDDのエンティティとクリーンアーキテクチャのエンティティ ○ 完全に同じものではないのだが、全く違うものでもない ● いろんな意見がある ○ ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティ │ nrslib ○ Entity in DDD ≠ Entity in Clean Architecture - Qiita ○ Clean ArchitectureのEntityとDDDのEntityは同じものです - Qiita

Slide 33

Slide 33 text

© 2020 EXNOA LLC エンティティという言葉について（2/3） 33 ● クリーンアーキテクチャのエンティティ ○ どのアーキテクチャにも言えるルールの話（抽象的な話） ● DDDのエンティティ ○ 戦術的設計としてのもう少し具象な話 ● Value Obiect（DDD） ○ クリーンアーキテクチャでは言及されていない（具象だから） ■ だけど、DDDのValue Objectはクリーンアーキテクチャのエンティティというアーキテクチャのルールを守っているはずである ■ もちろんDDDのエンティティもクリーンアーキテクチャのエンティティというアーキテクチャのルールを守っているはず

Slide 34

Slide 34 text

© 2020 EXNOA LLC エンティティという言葉について（3/3） 34 ● 要するに ○ 抽象概念のエンティティと具象のエンティティを同じか？と議論している ■ 正確には違う ○ クリーンアーキテクチャで実際に組まれたアーキテクチャのエンティティ（具象）をクリーンアーキテクチャのエンティティと呼んだ時 ■ DDDのエンティティを参考にしていたら同じといっていいかもしれない同じってなんなんだろう…

Slide 35

Slide 35 text