亀田2017年11月10日モデルでドメイン知識を表現するとは何か[DDD]この記事がすごくいいこと書いてる感じなので、今からDDDに沿った設計をしようと考えてる弊社のプロジェクトメンバーでぜひ共有したい!と思い、コードリーディング会をやってみました。得た知見を共有知にできるみたいな効果を目指しました。やってみたオフィスにいたプログラマ4人で一緒に内容を読み合わせ、悪いコード例、いいコード例について議論しました。以下のような知見/気づきを得ることができました。セッターがあるとオブジェクトの状態を変えれてしまうのでよくない。基本セッターがないオブジェクトとしてクラスを設計しよう。ドメインモデルにドメインの知識を集めることで、得られるもの。不変条件をコードで表現できるので、プログラムが壊れにくくなる。アプリケーションサービスのコードからマジックナンバーを除外でき、見通しが良くなる。コマンドメソッドであっても、ドメインモデルが副作用を起こすのは気持ち悪いので、内部状態を変更するのでなく、新しいオブジェクトを返す方針でいきたい、という意見も出た。コードリーディング会の良さDDDの具体的なコード例を見ながら議論することで、机上の空論ではなく地に足を付けた議論ができたなー、と感じました。いうコードが悪くてどういうコードがいいのか、ということを実例を見ながら具体的に話し合うことができました。「DDDで書いたときの嬉しさ」について共有できたのではないかと思います。個人個人で考えている「こういうコードがいい」という指針があることに気づけたのも良かったです。それらを言語化して共有するきっかけになったのが良かった。いう意識の共有は、違うメンバーが書いたコードでも統一感を保つために重要なことだと思うので、こういう機会を今後も設けていきたいですね。今後もこの程度の難易度のコードリーディング会をやっていきたいですね。準備が面倒だったりすると続けられなくなるかもしれないので、かるいスナック感覚で続けられるといい感じかなと思います。がんばらないと続けられない活動だとしんどくなってくるので、がんばらずに続けていきたい。