CleanArchitectureとは

https://qiita.com/nrslib/items/a5f902c4defc83bd46b8

レイヤーに基づいてディレクトリを構成することの課題

こんな感じ

https://qiita.com/hirotakan/items/698c1f5773a3cca6193e

└── src
    ├── app
    │   ├── domain
    │   ├── infrastructure
    │   ├── interfaces
    │   │   ├── controllers
    │   │   └── database
    │   ├── server.go
    │   └── usecase

デメリット

PJの規模が大きくなると顕著に現れる

• 各層のpackageが肥大化
• パッケージの行き来が煩雑

選択肢

• CleanArchitecture(レイヤー × Re-ducks構成)を採用する
• レイヤー構成を続ける
• CleanArchitectureやめる

レイヤー × Re-ducks構成

参考

https://qiita.com/inosy22/items/ce4a6ea7545c5cefd24b

単純なRe-ducks構成にしない理由

• 単純なRe-ducks構成 = 完全に機能・ドメインでパッケージ分ける
• entity, repositoryは別ドメインのusecaseから呼び出されるケースがある
• entity, repositoryは別出しにして、どの機能ディレクトリからでも呼び出して良いようにしておく

Re-ducks構成

https://speakerdeck.com/kenthamaguchi/mediado-go-2-clean-architecture

レイヤー × Re-ducks構成やってみた

構成

• 基本的に参考記事の通り
• app/{domain}配下はひとつのパッケージで良さそう
  • Goはpackage privateであり、CAのAdapterとUsecaseが同じパッケージに入ってしまっているが、トレードオフで許容範囲か
    • 例えば、interactorからpresenterの実装を呼ぶことができてしまうが、しないようにする（通常はしたくなることもないはず）
  • 複雑なドメインの場合、1パッケージだと辛いかも？
    • app/{domain}配下にadopterやusecaseといったパッケージを作るのもあり

メリット

• レイヤー構成のデメリットをほぼほぼ解決できそう
  • app/{domain}配下に集約しててみやすい、パッケージの行き来も少なくなる、CAの各レイヤーパッケージの肥大化も解消される
  • レイヤー毎にパッケージ化しなくなったことで、構造体名がシンプルになる

デメリット

• wire, interactorで若干つらみ
  • interactorからentity, repositoryを呼ぶ際に、自動インポートが効かなくなる
  • entity, repositoryにそれぞれaliasをつける必要がある
• 若干オレオレディレクトリ構成なので、とっかかりづらい？
  • CAとRe-ducksのふたつを理解している必要がある
  • レイヤー構成ならネットにたくさん記事があるので、親しみやすい？
• app, entity, repositoryディレクトリ配下にそれぞれ{domain}ディレクトリができる
  • 先述の通り、entity, repositoryを別出しするのは仕方ない認識
• 以下の図のように機能間に依存関係がないことを前提としているため、この依存関係があると結構苦しくなる