モデルでドメイン知識を表現するとは何か[DDD]
この記事がすごくいいこと書いてる感じなので、今からDDDに沿った設計をしようと考えてる弊社のプロジェクトメンバーでぜひ共有したい！と思い、コードリーディング会をやってみました。
コードリーディング会
みんなでコードリーディングすることで、
- 学習負荷を下げ、(僕が楽するため 🙂 )
- 疑問点も即座に質問し合えて理解度も高まり、
- 得た知見を共有知にできる
みたいな効果を目指しました。
やってみた
オフィスにいたプログラマ4人で一緒に内容を読み合わせ、悪いコード例、いいコード例について議論しました。
以下のような知見/気づきを得ることができました。
- セッターがあるとオブジェクトの状態を変えれてしまうのでよくない。基本セッターがないオブジェクトとしてクラスを設計しよう。
- ドメインモデルにドメインの知識を集めることで、得られるもの。
- 不変条件をコードで表現できるので、プログラムが壊れにくくなる。
- アプリケーションサービスのコードからマジックナンバーを除外でき、見通しが良くなる。
- コマンドメソッドであっても、ドメインモデルが副作用を起こすのは気持ち悪いので、内部状態を変更するのでなく、新しいオブジェクトを返す方針でいきたい、という意見も出た。
コードリーディング会の良さ
DDDの具体的なコード例を見ながら議論することで、机上の空論ではなく地に足を付けた議論ができたなー、と感じました。
どういうコードが悪くてどういうコードがいいのか、ということを実例を見ながら具体的に話し合うことができました。「DDDで書いたときの嬉しさ」について共有できたのではないかと思います。
また、個人個人で考えている「こういうコードがいい」という指針があることに気づけたのも良かったです。それらを言語化して共有するきっかけになったのが良かった。
こういう意識の共有は、違うメンバーが書いたコードでも統一感を保つために重要なことだと思うので、こういう機会を今後も設けていきたいですね。
最後に
お題に使わせていただいた記事の著者である @little_hand_s に感謝いたします。
今後もこの程度の難易度のコードリーディング会をやっていきたいですね。準備が面倒だったりすると続けられなくなるかもしれないので、かるいスナック感覚で続けられるといい感じかなと思います。
がんばらないと続けられない活動だとしんどくなってくるので、がんばらずに続けていきたい。
では。
京都オフィス勤務のエンジニア。アジャイル開発のエキスパートで、お客様とのコミュニケーション能力も高く、ファシリテーターとして各方面で重宝されているため多忙を極めている。