【現場で役立つシステム設計の原則】ドメインオブジェクトの見つけ方

現場で役立つシステム設計の原則をよみ直している

ドメインオブジェクトの見つけ方

かなり適当に言ってしまうと、会話だと思いました！ (実際、そう書いてある)

この辺は僕もあやしくて、多分こんな感じーって実装してしまいます

ですが、優秀なエンジニアさんはめっちゃ聞きますw

業務でやってることや困ってることを聞いて、それを解決するアーキテクチャを決めてコードを書くって流れでしょうか

そう、いいプロダクトは会話からできると言っても過言ではないかもですねー

ま、人が使うものを人が作るわけで当たり前と言えば当たり前です

見つけ方ですが、ざっくり全体のフローを聞き取りしてから、手帳なりホワイトボードなりに書くのがよさそうです

プロジェクトチームから常に見えるところに、ドットペーパーに付箋を貼っておくのもいいかも

業務の関心ごとをヒト、モノ、コトに分類して整理する方法が紹介されています

業務を理解するときに使う図法も紹介されています

これらの図から、ドメインオブジェクトを見つけクラスにしていきます

そう、ドメインモデルは業務知識の塊なのです

なので、新たな業務が発見されると、必然的にクラスが追加され、そのクラスにはロジックが記述されます

そうして、業務知識を得ながらドメインモデルを育てていきます

もっとも大事だと感じたのは、クラス名やメソッド名ですね (ここも僕はいまいち自信がないw

業務で使っている言葉を、ドメインモデルに起こして、ロジック (処理) がメソッド名とマッチしていれば、業務知識(ドメイン)がコードに落ちている状態だと言えますね

うん、あとから参加したメンバーにもわかりやすく良さそうです

中途半端なドキュメントを保守するより、業務ドメインをコードに落とし込み、テストコードで仕様を確認できるとすばらし