10月02日

質問者さん

外部システムとの連携の際に、その外部システムの制約でCookieを使う場合についてどのように設計するべきかの質問となります 通常であれば自身のシステムでCookieを元にUserIdなどを取得して、それ使って外部システムにリクエストをすると考え、その場合はUserIdやXxxRepository.getBy(UserId id)のようなインターフェースがドメイン層に登場するかと思っています ですが外部システムの制約上、Cookieをリクエストに付与することしか受け付けない場合、リポジトリーの引数にCookieが登場してしまい、技術的関心ごとがドメイン層に登場してしまうのは良くないと考えています 稚拙ながら検討した内容は以下となりますが、その他より良い選択肢などがあればご教授頂きたく質問しました A: ドメイン層にCookieが登場してしまうことを許容する B: リポジトリインターフェースをプレゼンテーション層などで定義する C: 引数不要のアクセスしたユーザー自身の値を取得するXxxRepository.getOwn()インターフェースとそのリポジトリを生成するXxxRepositoryFactoryインターフェースをドメイン層に定義し、インフラストラクチャー層で実装する

10月07日

松岡@ログラス/DDD,アジャイル

松岡@ログラス/DDD,アジャイルさん

認証情報をCookieから取得する、というのはあくまでプレゼンテーション層の事情なので、それをユースケース層とドメイン層に意識させないために、取得した値だけを受け渡せばいいのです。 以下のようにすることで、層の依存関係を守ったまま実装できます。 1.ドメイン層に定義するリポジトリインターフェイスのメソッドの引数はUserId型のクラスにする 2.プレゼンテーション層でCookieから値を取得し、UserId型に詰め替えてユースケース層のメソッドに渡す 3.受け取ったUserId型のインスタンスを使用してリポジトリを呼び出す

松岡@ログラス/DDD,アジャイルさんに 質問してみましょう!

松岡@ログラス/DDD,アジャイル

松岡@ログラス/DDD,アジャイル

DDDや設計にお困りの方はDMにてご相談ください。講義、モブモデリングやコーディングなどご要望に合わせた進め方でサポートします(オンライン)。 YouTube: https://www.youtube.com/channel/UCbHtbIUxtfGjrDy1WcqxExw

関連する質問

10月10日

続き質問

ご回答ありがとうございます Twitterの方でも他の方が被せてくださった説明も合わせて拝見しました 「Cookieは技術的関心ごとだからインフラ層に閉じ込める」という考えに固執しすぎていたこと、またリポジトリに対する理解も深まり、具体的な実装イメージも付き非常に助かりました 追加の質問ではないですがこの場を借りてお礼を申し上げます

10月10日

続き質問

はい、おっしゃる通りでリクエストヘッダーにCookieを載せた状態でのリクエストが求められる状況です もう少しシステム間の連携部分を詳細に説明すると、 システムA: 開発対象 システムB: 依存している外部サービス システムAに認証Cookieをリクエストヘッダーに付与してリクエスト その後システムAがリポジトリを使って集約を取得 この時リポジトリの実装では、システムAのコントローラーが受け取った認証CookieをそのままシステムBのリクエストヘッダーに付与してリクエスト(この部分が制約) となります システムAもBも /me エンドポイントに認証 Cookie を付与した状態で get リクエストを投げる必要があるイメージです

10月08日

続き質問

ご回答ありがとうございます 通常であればご回答のようにCookieからUserIdに詰め替えてリポジトリを呼び出すことについては理解しているのですが、本件の質問内容としては、リポジトリで呼び出される外部システムのAPIの制約として、「UserIdを使わずにCookieをリクエストに乗せること」が制約条件にある場合、どのような手段が取れるか、といった趣旨となります

松岡@ログラス/DDD,アジャイルさんが

最近答えた質問

07月17日

ドメインモデル図の作成について教えてください。 考えられるユースケースが3つあったとして、まず1つ目のユースケースに絞ってドメインモデル図を作成したとします。 その後に2つ目のユースケースに対してドメインモデル図を作成するとき、1つ目を拡張する形で作るのでしょうか? それとも別個のドメインモデル図として作った方が良いのでしょうか?

07月08日

ドメインモデルのコンストラクタ内でランダム値を生成する設計とテストについて相談です 現在、ドメインモデルのコンストラクタ内で各プロパティのルール検証を行いつつ、特定のプロパティ(紹介コードなど)にはランダムな値を生成しています。 この場合、テストコードで構造体の完全一致を検証することができず、設計とテストの整合性について悩んでいます。 私が考えた案は以下の通りです: ➀ランダム値生成を関数引数として外部から渡す設計に変更(依存注入) ➁構造体全体ではなく、必要なフィールドのみを個別に比較する ➂テスト時のみランダム生成関数にフックを仕込んでモック化する ただし、③の方法については、今後モックが複数発生しテストが肥大化していく懸念があります。 ご相談したい点 ・上記のような状況において、松岡様が考える最も適切な対応方針はどれでしょうか? ・そもそも、コンストラクタ内でランダムな値を生成すること自体が設計としてNGなのかどうかもご意見いただきたいです。 なお、似たようなパターンとして、ユーザーモデルのコンストラクタ内でパスワードのルール検証後にハッシュ化を行っているケースもあり、 こちらも構造体の完全一致によるテストができていない状態です。

07月08日

DB更新でユーザーIDを格納する場合、ユーザーIDは集約に含めるべきですか? それともリポジトリの実装側でセッションから直接取得しますか?