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

結論 nullガードと nullable→non-null の変換はインフラ層（リポジトリ実装）の責務とします。 判断の基本とさて、まず「その実装はどの層の責務か？」を最初に考えるのが超重要ポイントです。 依存方向に従い、依存される側を優先します。(ドメイン層 > ユースケース層 > プレゼンテーション層／インフラ層）。 ドメイン層の扱い ドメインは non-null 前提でモデリングし、プロパティと reconstruct で表明します。 「DB では nullable である」はインフラ層の知識であり、ドメイン層は関知しません。 したがってドメインは factory ではなく reconstruct で non-null を受け取るだけでよいです。 もしfactory でチェックすると、「DB では nullable である」というインフラ層の知識がドメイン層に漏れ出す。これは責務違反になります。 ドメイン表現と永続化表現の変換は、リポジトリ実装クラスの責務です。永続化の方法が RDB でもインメモリでもファイルでも、その技術的詳細を隠蔽するのがインフラ層の役割です。DBだnullable、というのもそのようなインフラ層だけが知っておくべき知識の一つです。 non-null のはずの項目が null で来た場合は、リポジトリで整合性エラーとして検知します。