以前に投稿した内容を再考して、ブラッシュアップしようという内容です。
以前の記事はこちら
そして結果としては以下の構成が第2の構成です。
. ├── domain ├── driver │ └── model ├── gateway ├── port │ ├── input │ └── output ├── rest └── usecase
フォルダ構成がとてもスリムでシンプルになりました。
前回との違い、方針など
不用意にディレクトリ(Package)を生やさない
前回はレイヤー毎にフォルダを作成し、内部で責務単位でPackagingしていた。
例) 前回までのinfrastructure
. ├── infrastructure │ ├── rest │ └── driver ...
上記を採用した場合は、
- 最下層Pathまでのフォルダが深くなり
- 中間層Pathまでにコードファイルが作られやすくなる
ちなみに、
細かいhttp clientを拡張したものなどはpackageを作るか迷った挙句、infrastructure直下にgoファイルを置くような構成をとりました。
前回まではこんなことを言ってるのに、今は真逆の発想をしている。
何が起きたかというと、infrastructure packageがcommonフォルダ化してしまい、変なutilが作られそうになったためだ。
Repositoryという言葉をやめた
Repositoryという言葉はDDDの文脈で使われており、Gatewayに統一した。
Portが抽象でPortの実装がGatewayってことですね。やることはそんなに変わっていません。
Controllerをやめた
これは迷ったのですが、REST APIを作る上ではControllerは過剰な気もしており、やることといったらInputのValidationとUsecaseの呼び出し程度にとどまる。
そのため、わざわざレイヤー化,Packagingするほどか？って感じで一旦消すことにした。
また、Inputしたものを変換するときによほど複雑なロジックがあるとかではないかぎりドメインのFactoryを作れば吸収できる範囲だと思う。
ひとまずこれでやってみる
まだまだ試行錯誤をして模索しているのですが、一応スッキリしてきたのでひとまずまとめました。
