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

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

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で扱いたい文脈が存在するため変更しない、という前提でご教示いただきたいです）

いつもお世話になっております。DDDを実践していて以下の点が気になりましたので質問させて頂きたいです。 例えば、あるエンティティが、自分が持っている属性ごとに異なる計算（ifやswitch）をしているメソッドがあるとします。（演劇エンティティの場合：タイプがコメディの場合の料金計算処理とタイプがシリアスの場合の料金計算が条件分岐分かれているメソッドを持っている場合など） 今後の改修で演劇タイプがどんどん増えてきた場合、メソッド内の条件分岐もどんどん増えていくことになります。この場合どのようにして保守性をあげれば良いでしょうか？ ストラテジやサブクラスによる対応をした時にドメインモデルとの差が出てきてしまい、悩んでおります。ご回答いただけると幸いです

ドメインモデルにてモデリングしたエンティティを抽象クラスかインターフェースにして、それを実装するクラスでドメインモデルに出てくる種類、区分を表現するのは良いでしょうか？