ドメイン層の実装

テラソルーナガイドライン
いわゆる「モデル」をEntityと言っている?

Entityの実装
- 基本テーブル毎, 中間テーブルのEntityは作らない
- FKはEntity又はEntityのList, Setで表す
- カテゴリカルデータはEntityではなく String 等の基本型で表してEnumにすべき
Repositoryの実装
- Entityのライフサイクルを制御(CRUD), 永続化する操作
  - 実際のAPIはinfra層のRepositoryImplで実装, infraに依存してはいけない
- CRUD以外にも findOneBy, findAllBy, findPageBy, countBy, existsBy が必要になるかも
Serviceの実装
- ビジネスロジックを書く, 間違った共通化が行われないように再利用性は考慮しない
  - 特定のControllerに対するビジネスロジックの提供が目的
- 他サービスから呼び出すのは原則禁止, そうしたいなら SharedService にすべき
  - サービスがサービスを呼ぶことの是非
- 複数Controllerから呼ばれるがそれによる分岐が入る場合は分岐を別サービスに分けて共通処理は SharedService に
  - 依存が不正になるので
- データはRepositoryを介してEntityとして取得

開発の流れ

単一, 相関validationはControllerですべき
- ex. Bean Validation
modelへの変換, modelからの変換はControllerですべき
- やはりそう, 指摘したが
- DDD の文脈では, 外部オブジェクトとの変換はDTOに任せるべき
トランザクション境界はServiceに設ける

Q: domainにinfraが混入することを100%防げるのか? -> A: 出来ない

DDD の文脈だと区別する todo

Service層にAtomic Designの考え方適用できないかなー

ServiceとSharedServiceの階層の話を一般化する話?