30482


ドメイン駆動設計の情報を漁っているとドメインモデルにリポジトリへ保存するメソッドを持たせていたりするコードを見かけたことがあります。  
たとえば以下のようなコードです。

[code]

    case class User (id: Long, name: String, age: Int)(userRepository: UserRepository) {
      def save()(implicit ctx: ExecutionContext) = {
        userRepository.save(this)
      }
    }
    
[/code]

しかし、果たして永続化という行為はドメインモデルに持たせるものなのでしょうか？  
私の認識ではアプリケーション層のアプリケーションサービスがトランザクション制御の役割をになってアプリケーションサービスで

[code]

    class UserService @Inject()(userRepository: UserRepository) {
      def regist(userCreateForm: UserCreateForm) = {
        // IdGeneratorというID生成器があると仮定
        val user = User(IdGenerator.nextId(),userCreateForm.name, userCreateForm.Age)
        userRepository.save(user)
        user
      }
    }
    
[/code]

という形であるべきなのでは？というように思っていますがDDDではどうあるべきなのでしょうか？


CC BY-SA 3.0
2016-11-16T14:54:18.437
30458
2016-11-17T08:55:05.673
19588
question
scala ドメイン駆動設計
ドメイン駆動設計におけるドメインモデルとリポジトリの関係


私たちは、ドメインモデルではRepositoryは使わないようにしています。  
おっしゃるとおり、それはアプリケーション層でやるようにしています。

・ドメインオブジェクトは業務上の判断／加工／計算のロジックだけを持つようにする  
・記録や参照という業務の関心事（永続化の関心事）は、アプリケーション層にまかせる

そういう役割分担を明確にしたほうが、業務ロジックをうまく整理できると考えています。


CC BY-SA 3.0
2016-11-16T15:48:26.843
30459
2016-11-16T15:48:26.843
8260
30458
answer


EvansのDDDにおけるリポジトリとファクトリの役割については、DDD本のRepositoriesパターンおよびFactoriesパターンに実はしっかり明記されています。

> **リポジトリ** と **ファクトリ**
> は、それ自体はドメインに由来しないが、ドメイン設計においては意味のある役割を持っている。これらの構成概念は、モデルオブジェクトを操作できるようにすることで、
> **モデル駆動設計** を完成させるものなのだ。

つまり、ドメインオブジェクトの生成と永続化というのは、「ドメインモデル」の一部ではないけれど、「ドメイン設計」の重要な一部だ、ということです。昨今のDDD論者の中であんまりここをしっかり強調して説明している人は少ないように見えますが、Evansは、DDDにおいて「ドメインモデル」と「ドメイン設計」というのをはっきりと区別して考えているようです。

上でモデル駆動設計との関連で説明されているように、「ドメイン設計」というのはつまりドメインモデルと実装とをつなぐために必要な「橋渡し」のようなものだと考えられます。

そこから翻ってご質問について考えると、ドメインモデルは実装に落とし込む中で必然的にドメイン設計を必要としますから、ドメインモデルの中にファクトリやリポジトリを含むオブジェクト生成／永続化のコードが入ってくること自体はDDDとしては問題ないです。ただし、それはドメインモデルの要素ではありません（つまりビジネスの関心事ではなくソフトウェアの関心事である）から、何らかの形で純粋にドメイン設計の部分をドメインモデルから区別できるようにコーディングすることは重要です。

どのようにこのドメインモデルの要素とドメイン設計の要素を区別するかについては、それこそDDD実践者の間で様々な流派があると思いますから、完全に永続化をアプリケーション層に隔離するのを好む人もいれば、妥協的にドメインモデルの中に入れ込むのを良しとする人もいます（Evans自体はDDD本を読む限り、原理主義者ではなく妥協を好むようです）。技術の進歩によっても、この部分は何がベストプラクティスかは常に変わっていくものだと思います。


CC BY-SA 3.0
2016-11-17T08:55:05.673
30482
2016-11-17T08:55:05.673
244
30458
answer