06月20日

質問者さん

リポジトリ層に定義する関数で、オーバーロードを使うべきか否かのご意見を伺いたいです。 update(foo: String), update(bar: Int) とするか、updateFoo(foo: String), updateBar(bar: Int) とするかです。

07月08日

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

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

メソッドのシグニチャ(名前、引数)から責務=何をするクラスかが明確になる方が望ましいです。その観点からすると後者だと思います。

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

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

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

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

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

最近答えた質問

07月08日

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

07月08日

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

07月08日

リポジトリ層に定義する関数で、オーバーロードを使うべきか否かのご意見を伺いたいです。 update(foo: String), update(bar: Int) とするか、updateFoo(foo: String), updateBar(bar: Int) とするかです。