ドメイン層

• ドメイン及びそのドメインに関するロジックを記述
• サービス間を跨って利用するロジックはドメイン層に記述
• リポジトリのインターフェースはドメインが持つ
• サービス層、ハンドラーに依存するのは禁止、つまりimportは禁止

例えば、パスワード自身はドメインになり、オブジェクト(値オブジェクト)として扱うことができ、パスワードにまつわるロジックはオブジェクトに紐づける。 この時、構造体にメソッドを紐づけるが、構造体のプロパティが各メソッドで必ず利用することで凝縮度が高いオブジェクトになる。 なるべく凝縮度の高いオブジェクトを作ることで可読性、堅牢性、信頼性が高くなる

ファイル・ディレクトリ

model/

• 値オブジェクト、エンティティ
• システム固有ドメインに対するビジネスロジックなどを記述する

service/

• サービスドメイン
• 値オブジェクトやエンティティに記述するとドメイン的に不自然になる場合はドメインサービスに記述
• なるべく利用しないようにする
• ファイル名は{ドメイン名}_service.goとする

不自然な振る舞いの例

1. ユーザの重複を確認することを考える
2. ユーザの重複をエンティティに記述すると、ユーザー自身に自身の重複を確認するという現実世界ではおかしな振る舞いになる
3. その場合、ユーザサービスドメインに記述する

interface.go

• サービス層またはドメイン層と、リポジトリ層を繋げるインターフェースを記述する(依存関係の逆転)
• より上位レベルにインターフェースを持たせる必要があるためドメイン層に配置
• サービス層またはドメイン層は必ずインターフェースを利用してリポジトリを操作すること