質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
ドメイン駆動設計

ドメイン駆動設計(Domain-driven design, DDD)とは、ソフトウェアの設計手法、および設計思想や哲学のことです。ドメインモデル構築の際に、設計上の判断を決定する枠組みとドメイン設計に関して議論するボキャブラリを提供するものです。

Q&A

1回答

1068閲覧

DDDにおけるドメインオブジェクトはリソースと1対1で対応すべきものですか?

Nosada

総合スコア0

ドメイン駆動設計

ドメイン駆動設計(Domain-driven design, DDD)とは、ソフトウェアの設計手法、および設計思想や哲学のことです。ドメインモデル構築の際に、設計上の判断を決定する枠組みとドメイン設計に関して議論するボキャブラリを提供するものです。

0グッド

2クリップ

投稿2021/10/28 13:47

例えば、DBのusersテーブルに保存されるレコードをリソースとして想定すると、同じリソースではあるものの、

  • 新規保存のために受け付けた入力を変換したオブジェクト
  • ビジネスロジックにより、入力を加工して新しいデータが追加された(ex.登録ステータス)オブジェクト
  • 既にDBに保存されているものを取得した結果を変換したオブジェクト

など、複数のオブジェクト(あるいは同じオブジェクトで定義されたプロパティの数が異なるもの)が存在しうるかと思います。

よりよい設計を考える場合、これらはそれぞれ別のオブジェクトとして定義され、ビジネスロジックの中でこれらのオブジェクトが順次変換されていくような設計が望ましいのでしょうか?

あるいは、同じオブジェクトとして定義され、それぞれのプロパティに(nullableである、のような)性質が記述されている方が望ましいのでしょうか?

安全性を考えるなら前者の方が望ましいように思えますが、同じものを扱っているのにユースケース次第で別の概念として定義されるのは正しいのか?など、自分では結論が出せずにいます。

どなたかお詳しい方がいらっしゃればご教示頂きたいです。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ドメインオブジェクトと、それがRDBなどにシリアライズされる際のデータ形式は分離して考えたほうがいいですよ。

たとえば、以下のようなユースケースを想定してみてください。

UserAccountRepositoryは抽象であり詳細は隠蔽されています。UserAccountRepository#findById, #storeが定義されており、具体的な実装であるI/O処理はオブジェクトを読み込んだり書き込んだりできればよいだけです。この設計では、UserAccountRepositoryがRDBに対応するかNoSQLに対応するかは本質的な問題ではありません。もちろん、機能するにはUserAccountRepositoryOnMySQLのような具体的な実装は必要ですが、このユースケースでは方針となる抽象型だけが重要です。

java

1classs RenameUserAccountUseCase { 2 UserAccountRepository userAccountRepository; 3 4 RenameUserAccountUseCase(UserAccountRepository userAccountRepository) { 5 this.userAccountRepository = userAccountRepository; 6 } 7 8 void execute(UserAccountId userAccountId, LastName lastName) { 9 // リポジトリからドメインオブジェクトを取得する 10 UserAccount userAccount = userAccountRepository.findById(userAccountId); 11 // ドメインオブジェクトのビジネスロジックを呼び出す 12 UserAccount userAccountRenamed = userAccount.renameLastName(lastName); 13 // 最新のドメインオブジェクトをリポジトリへ保存する 14 userAccountRepository.store(userAccountRenamed); 15 } 16 17}

よりよい設計を考える場合、これらはそれぞれ別のオブジェクトとして定義され、ビジネスロジックの中でこれらのオブジェクトが順次変換されていくような設計が望ましいのでしょうか?

あるいは、同じオブジェクトとして定義され、それぞれのプロパティに(nullableである、のような)性質が記述されている方が望ましいのでしょうか?

UserAccountRepository内部でUserAccountがどのようなテーブルにマッピングされるかという問題ですよね。それはどういう形式でもよいですが、トランザクション境界は合わせてください。UserAccountは集約のルートエンティティです。集約はオブジェクトの整合性を担保する境界なので、リポジトリでI/Oする際必ず集約の単位で行います。集約内部の一部のオブジェクトだけを読み込んだり保存したりはできません、原則的には。集約はそれ以上分割できないアトミックな単位です。

結局のとろこ、リポジトリの責務からみた場合はオブジェクトをどういう形式でI/Oするかしかないです。極端な話ですが、XMLに変換してファイルに保存して読み書きする実装も可能です。そういう意味でいえば、リポジトリは永続化されるコレクションのように見える責務ですね。

投稿2021/11/28 00:12

j5ik2o

総合スコア41

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問