ドメインオブジェクトと、それが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に変換してファイルに保存して読み書きする実装も可能です。そういう意味でいえば、リポジトリは永続化されるコレクションのように見える責務ですね。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。