質問者さん
リポジトリの戻り値と詰め替えについて教えて下さい
アプリケーション層とプレゼンテーション層のやり取りにおける値の変換はアプリケーション層の責務であるとの記述がありました。
インフラ層(リポジトリ)とアプリケーション層のやり取りの際にはどこで変換を行うべきでしょうか。
なお、値の変換処理はアプリケーション層にサービスとして書いています。
①アプリケーション層で行う場合
単純な読み取り処理の場合はインフラ層の戻り値→ドメインオブジェクト→プレゼン層用の形式、と即座に二回変換することになり違和感があります。
②インフラ層で行う場合
アプリケーション層のサービスをインフラ層が直接呼び出していいものでしょうか。
2024年04月25日
松岡@ログラス/DDD,アジャイルさん
レイヤー同士の依存関係は、オニオンアーキテクチャがよく整理できるかつシンプルなのでおすすめです。
オニオンアーキテクチャの解説はこちらご覧ください。このレイヤーの前提で話をします。
https://little-hands.hatenablog.com/entry/2018/12/10/ddd-architecture
リポジトリは、インターフェイスをドメイン層において、実装クラスをインフラ層に置きます。
リポジトリに入出力するオブジェクトの的周りのことを集約と呼ぶので、リポジトリのメソッドの引数や戻り値は集約のオブジェクトです。
ドメイン層にはインターフェイスしか定義されていませんから、DBの値を取得して集約のインスタンスに詰め替えるのはインフラ層の仕事です。
集約のオブジェクトからユースケース層、プレゼンテーション層の戻り値に変換するのはそれぞれの層の責務です。ユースケースの戻り値をXxxDtoとするなら、そこに詰め替えるのはユースケース層の仕事です。
集約オブジェクトが1つならユースケースから直接返すこともあるかもしれません。
プレゼンテーション層の戻り値のオブジェクトがあるなら、そこに値を詰め替えるのはプレゼンテーション層の責務です。
一方、ユースケース層とプレゼンテーション層でそれぞれ戻り値のオブジェクトがあった場合、集約のオブジェクトから2回も詰め替えないといけないのでしょうか。これは層の責務としてはyesですが、ボイラープレート感ga
若干ありますね。その場合は手を抜くとユースケース層のオブジェクトをプレゼンテーション層でそのまま返してしまうと言う手はあります。一方、これはユースケース層の戻り値がAPIの仕様に影響すると言うことになるので、そこに直接的に影響させたくない場合は急がば回れでユースケース層とプレゼンテーション層に定義すると依存が切れます。
松岡@ログラス/DDD,アジャイルさんに 質問してみましょう！
松岡@ログラス/DDD,アジャイル
DDDや設計にお困りの方はDMにてご相談ください。講義、モブモデリングやコーディングなどご要望に合わせた進め方でサポートします(オンライン)。 YouTube: https://www.youtube.com/channel/UCbHtbIUxtfGjrDy1WcqxExw
松岡@ログラス/DDD,アジャイルさんが
最近答えた質問
11月04日
reconstruct運用時のFactoryメソッドの必要性について質問させてください。
エンティティの初期化は松岡さんの書籍と同様、reconstructで実装しています。
エンティティのプロパティがすべてnon-nullableの場合、基本的にはresonctructの引数もすべてnon-nullableになると思います。
しかしDB側ではnullableなデータとして扱っている場合、初期化前にnullガード（バリデーション）を行う必要があると思いますが、それをインフラ層で行うとドメインロジックが漏れることになってしまいます。
かといってreconstructの引数をnullableにして内部でバリデーションすると、本来nullableではないデータを受け取ってしまう実装になり不整合の原因になると思いますし、nullableを受け取って例外出すなら最初からnon-nullableにしておくほうがモデリング的にも適切だと考えています。
このような場合の解決策としてFactoryメソッドを使って内部でバリデーション＋reconstructを行えば隠蔽できいいかなと思いましたが、初期化自体をreconstruct/factoryの両方から行えることになり、本来前者を使うべき場所で後者を使うなど運用面での問題が発生してしまうと思います。
（引数的にはfactoryがrepositoryを包含する関係になり、factoryが便利メソッド的に使われていく問題です）
またバリデーションやCompositeパターンにおける出し分けのように、Factoryという言葉がもつ意味合いも分散してしまい、結果複雑化し管理・運用が難しくなる気もしています。
（後者は def dollarでMoney("USD"), def yenでMoney("JPY")を出し分けるFactoryのイメージ）
松岡さんでしたらどのように対応するでしょうか。
（なおDB側をnon-nullableにすればいいという意見が出そうですが、nullableで扱いたい文脈が存在するため変更しない、という前提でご教示いただきたいです）
10月16日
いつもお世話になっております。DDDを実践していて以下の点が気になりましたので質問させて頂きたいです。
例えば、あるエンティティが、自分が持っている属性ごとに異なる計算（ifやswitch）をしているメソッドがあるとします。（演劇エンティティの場合：タイプがコメディの場合の料金計算処理とタイプがシリアスの場合の料金計算が条件分岐分かれているメソッドを持っている場合など）
今後の改修で演劇タイプがどんどん増えてきた場合、メソッド内の条件分岐もどんどん増えていくことになります。この場合どのようにして保守性をあげれば良いでしょうか？
ストラテジやサブクラスによる対応をした時にドメインモデルとの差が出てきてしまい、悩んでおります。ご回答いただけると幸いです
10月16日
ドメインモデルにてモデリングしたエンティティを抽象クラスかインターフェースにして、それを実装するクラスでドメインモデルに出てくる種類、区分を表現するのは良いでしょうか？