エンティティの識別子をラップしたクラスを用意するとよい理由

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。(あまり本質的な話題でなくてすみません。。。)

エンティティの識別子、どう実装していますか?

私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。

VoyageClass

ドメイン駆動設計本の例はどうでしょう・・・。

ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。

VoyageAndVoyageNumberClass

実践ドメイン駆動設計本では日付時刻を含んでいるような識別子を例にあげてこのような複雑な識別子はラップしたクラスを使うべきとあります。

要は識別子の複雑さや使われ方によるのかなと思います。

という曖昧な結論では記事になりませんので、識別子用のクラスを持つことで効果がでるケースを紹介したいと思います。

例は、よくある求人サイトの想定で、求職者が求人に応募するようなモデルです。

まずは、求人パッケージ(モジュール)。
求人

そして、求職者パッケージ(モジュール)。
求職者は求人に応募しますので、応募クラスは求人IDクラスを持っています。
求職者

・・・と、クラス図だけではなんてことないのですが、パッケージ図を見るとこうなります。
求人サイト

これが求人や求職者の識別子がプリミティブな型の場合は以下の通り依存関係を持つことはありません。

求職者2

求人サイト2

実装上はこれでも問題ないのですが、ドメインの知識をソースコードに反映するということを考えると、パッケージ間の依存関係がきちんと表現できるとよりわかりやすい設計になると思います。

エンティティの識別子はそのエンティティの同一性を保証してあげるだけの役割ですので、わざわざラップして使う必要がないと思いがちです。
しかし、ラップして使うことで、プリミティブな型をそのまま使うことに比べてモデルをより豊かに表現することができ、ドメインの知識をより深く理解する手掛かりとすることができます。

ぜひ試してみてください。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

※ アイキャッチ画像(Original Update by paurian https://www.flickr.com/photos/paurian/3707187124)

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中