🏗️ ドメイン駆動設計と依存性逆転の原則

社内LTにて、ドメイン駆動設計と依存性逆転の原則を布教しましたʕ◔ϖ◔ʔ はてなブックマークのコメントもどうぞ！ なお、ドメイン駆動設計を理解するためには、依存についても知る必要があります。 是非、依存関係と依存オブジェクト注入もご参照ください👍🏻

[wwolf]

自分はドメイン層がリポジトリに依存してもOK派。依存関係を逆転させたい時はインフラ層を丸ごと差し替えたいというニーズがある場合だけで、普通はそんなニーズ無いので。Strategyパターンで十分でしょって言う...

[snowcrush]

集約の整合性を保証するためのリポジトリとデータ永続化パターンとしてのリポジトリは全然意味が異なるのだけど混同されがちだなあ。まあコード上は混ぜて使われることが多いからしょうがないんだけど。

[turanukimaru]

リポジトリは抽象もドメイン層には入らないの！ユーザに「リポジトリ」って言ってもわかんないでしょ!?永続化の概念自体をドメイン層から取り除くの！薄々感じてたけど皆ドメインというかドミナス理解してないだろ!?

[nunulk]

言われてみるとたしかに「リポジトリ」はドメインの言葉ではなくパターン名だな。概念としてはドメインオブジェクトの集合に対する操作の集まりなのでドメインのものだとは思うけど

[little_hands]

僕はリポジトリのIFはドメイン層派。集約を表現する唯一のコードがリポジトリで集約の知識はドメイン層にあるべきだから。ユースケースによって集約の範囲が異なると困る。取り除くのは永続化の「方法」に関する知識

[cl-gaku]

ドメインを永続化するインターフェースとしてのリポジトリはドメイン層に含む派だな

[chiroruxx]

エヴァンス本で紹介されてるアーキテクチャと、ドメイン駆動設計は全くの別物だと思うんだけども。ドメイン駆動設計はアーキテクチャパターンではない。

[n314]

自分はリポジトリのインターフェースはユースケースに置くようになってきた。結局SQLはユースケースによって変わっちゃうのと、抽象の実装でレイヤーを飛び越えたくないので。

[masatotoro]

DDD。アーキテクチャの整理が分かりやすい

[hirorinya]

学び