ドメインをパッケージにするといいかも

Goのパッケージ名は簡潔で明瞭な名前が好まれる。

ドメイン駆動設計やクリーンアーキテクチャの文脈では

• domain
• model
• usecase
• repository

のように分類ごとにパッケージが切られてしまう傾向があるけれど、上記のブログ記事によれば

全APIを単一パッケージにしない 多くの善意なプログラマは、コードベースの中でエントリーポイントを見つけやすいように 公開するすべてのインターフェースを api、types、interfaces といった名前の単一のパッケージに まとめています。これは間違いです。そのようなパッケージは util や common というパッケージ名で 起きた問題と同じ問題に悩むことになります。つまり境界がどんどん大きくなり、ユーザにわかりにくく、 依存が強くなり、他のインポートしたパッケージと名前がぶつかるといった問題です。

とあって、これに当てはまっていると思う。

Goと設計とDDDにもあるが、レイヤー(層)が存在するのは分かるし概念としては必要だけど、それがそのままパッケージとして表出するとかえって面倒になる。具体的にはGoではパッケージ単位でカプセル化を行うが、レイヤー単位でパッケージを切ると全て同じパッケージに入ってしまうので、関係のない領域のプライベートな型や関数が見えてしまう。

それよりは、レイヤーはディレクトリとして存在するが、ドメインは個別のパッケージに分割する方が自然なのではないか。

• internal/domain/billing (請求)
• internal/domain/invoice (領収書)