DDDに関わるアーキテクチャ
DDDにまつわるほげほげアーキテクチャの用語を整理する https://gyazo.com/a440b26cce7fb5d7890067fc2be9c58c
👎infra層の都合にDomain層が依存している
今積極的にlayered architectureを選択する理由はない？kadoyau.icon
各レイヤーの説明
UI
input/output
例
view
レスポンス整形とか
Application
Domain
Infrastructure
ドメインのインタフェースの実装
何が何でもドメイン層のロジックを実現する
実際のシステム構成に依存/考慮した実装になるため、必然的に泥臭くなる
インフラ関連の接続に必要なクラス（RedisとかMySQLの接続クラス）は別ディレクトリのほうがいいかも
https://gyazo.com/4d066ea1b22b2730ac3020954a2c944e
リクエストは各レイヤを必ず上から順番どおりに通る
https://gyazo.com/e1256daefb0eef68eb5ffdd9c57908a8
https://gyazo.com/4df38ec2d5f7e302e56f7c87ee4052c9
/icons/重要.icon ドメインは何にも依存していない
layered architectureはドメイン層がインフラ層に依存している。一方、これらはドメイン層は何にも依存していない（依存性逆転の原則） ドメイン層は実装の都合なんか考えない理想の世界を描く。よって処理が効率的ではないコードになることがある
実装はインフラ層で頑張る。たとえばデータを永続化することを想像しよう。MySQL向けのドライバーを使った実装をしたり、チューニングしたりするだろう
ドメインは永続化されるストアが何かには興味がない。インタフェースの通りに動けば(与えた引数によって正しい型の値が帰ってくれば)なんでも良い
このレイヤリングによって、インフラ層を変えれば、実装を差し替えられることができる。未来にすごいインフラができたらそっちをつかってめっちゃ効率化できるかもしれない。そのときにドメインのコードは修正の必要がない。
これが飲めない場合、「どれぐらいDDDするか」みたいな会議が始まる
ドメイン層に具体的な名前をつけると破綻する
例
getHogeByApi() -> APIでとらなくなったら破綻
getPoyoRecords() -> DBからとらなくなったら？
ここ理解と上の図があっていないkadoyau.icon
Use Case層のオブジェクトは、Domain層のEntityのうち、そのUse Caseで興味のあるEntityを返す
code:_
Domain: () => GenericEntity
UseCase: (who, what, for) => GenericEntity
Presantation: (GenericEntity) => SpecificEntity
ここは現実的にはDomainのEntityを返してもいいと判断することがあるkadoyau.icon
Presantationは、Use Caseが返したEntityから、必要な情報だけを取り出した別のEntity（SpecificEntity）に詰め替える。ControllerはそのEntityを使う
なにをDomainにして何をUseCaseにするのか？
この記事の説明では、データ整合性の担保だけをするのがドメインで、それを利用したロジックはすべてApplication（UseCase）になっている
コードの寿命の違い：UseCaseは頻繁に変わる可能性があるが、ドメインは相当不変