初めてDDDを使ってみて悩んだところ

研修でDDDを使ったサービスを作ってみることになったが、DDDを使うのが初めてなので同じような状況の人向けに悩んだところをメモしておこうと思う。 DDDとは DDD（Domain-Driven Design）とはドメイン駆動設計と呼ばれる設計方法の一種で、複雑なビジネスの要件をソフトウェアで上手く扱うためのアプローチとなっている。（DDDの詳しい説明などは以下を参照） DDDはドメイン（業界領域）の複雑さにフォーカスを当て、ドメインに精通しているドメインエキスパートと呼ぶ人の協力を得てシステム開発を行ってい行く。また、DDDではクリーンアーキテクチャ、ヘキサゴナルアーキテクチャなどのアーキテクチャと共に用いられることが多い。（今回作っているサービスではクリーンアーキテクチャを採用しているつもりだが、他のアーキテクチャとの違いが正直良く分かっていない） サービスの概要 ざっくりと説明すると、

[hase0510]

idがnullのモデルは永続化前のエンティティです、ということにすれば「正しい」のでは

[atico]

画像記録を保存するという事と、フォローしている人の画像記録を見るという事は別のコンテキストなので、モデルも別で考える。DBを意識せず、ユースケース実現に必要なモデルで表す事でエンジニア以外も理解できる。

[ghostbass]

アカウントを作成、保守するのと投稿やらフォロワーへのアクションはユースケース分けないと困るのでは

[Chisei]

私なら createAccount() 専用の引数オブジェクトを定義することで id の無いモデルと id のあるモデルを分ける。あるいは要件によっては generateId() を定義して事前に DB から id を得る。

[maninthemiddle]

将来のDB分散化も視野に入れるなら連番idを避けておくのは正解だと思う

[mingos]

クライアント側でユニークなIDを生成する時にUUIDでは発行順にソートできないのでULIDを推奨したい。 https://github.com/ulid/spec

[turanukimaru]

良く勘違いされるのだが、全てが集約になるわけではない。例えば名簿は名前や連絡先のリストではあるが集約ではない。…集約であるか？ではなくてエンティティであるか？が大事なんだけど説明が難しすぎる。

[kazokmr]

"画面に表示される要素で考えてみるといい"ならば、アカウントモデルではなくてIDを持たないアカウント生成モデルとかファクトリーを用意すると良さそう