前振り
2023/11/12に技術書典15があり、オフライン参加した。
技術書典から一週間経ってもまっっっっっっっっっったく読む気配がなかったため、無理やり早起きしてスタバに行って30分という制限を付けて買った本を読んできた。
「Go言語で構築するクリーンアーキテクチャ設計」という本を読んだ。
どうせ、この場で誰もここを見てないだろうということで好き勝手に感想を書く。
そもそもなんでこの本を買ったかというと、仕事でGo言語を使っており、WebAPIでバックエンド構築に携わっている。
せっかくだし勉強も兼ねて、個人で何か作成したいと思ったときにそういえばどういう風に作成するのがいいんだ？と思うようになった。
個人で作成する小さいものは、PythonのFlaskで適当に作成することが多かったが、Goで作成しようとすると仕事のコードしか見ていないのもあって、何故か大規模化させたくなってくる。
そんなこんなで、少し興味をもったため買ってみた。
本編に入るまでにこんなに時間を使ってしまうとは本当に文章を書くのが苦手だ。
いや、口下手でもあるから得意なものなどないか。
軽い感想
この本を読んだ感想だが、普通にわかりやすいがAPI設計するときどうしようというのが解消していない。
「依存性の向きをビジネスロジックに向けさせる」ということらしい。はぁ？よくわからん。
クリーンアーキテクチャを検索するとよく、下の図に行き当たる。中心のEntitiesにビジネスロジックを置き、その周りに依存度の高い順に囲っていく感じである。
GoとGinで考えると、一番外側にGin(FrameWork)になり入出力のハンドリングをControllers,PresentersなどのInterface Adaptersで行い、UseCasesでビジネスロジックを書いているEntities(Domain)を呼ぶ出す。
うん。なにも見ないでさぁ作れって言われたら絶対無理だな。
結局、実装自体での依存をせずにInterfaceを間に挟んで、それに依存させろ。そうすれば、内部のロジックを変更したときに回りの依存度が下がるだろう。それを強く意識するために外部レイヤーから内部レイヤーへのアクセスを明確にしろって感じだと思う。
これってどこから書き始めるのが楽なんだろうか？内部から書いていって、Mock使いながらテストを書きながら外部へ順番に作ると作るとわかりやすいのかも？
何度も読んで、何度も書いて、血肉にしよう。