- 2024年11月25日
はじめに
こんにちは、ユニフェイスの角谷です。
普段、自分の書いたコードを見返すと「読みづらいな…」とか「テストコードが書きづらいな…」と感じることが多々あります。その原因として、オブジェクト指向の設計が不十分だったり、業務ロジックが適切に分離できていなかったりすることが挙げられると感じました。
そんなときに、『現場に役立つシステム設計の原則』という本に出会いました。同僚から「オブジェクト指向やドメイン駆動設計（DDD）についてわかりやすく解説されている」と勧められ、早速読んでみることにしました。
※以下はあくまで個人の感想です。ご了承ください。
全体を通しての感想
本書は、変数名の適切な命名やメソッドの分割といった基本的な「コードをきれいにする」内容から始まり、徐々にオブジェクト指向やDDDの考え方に展開していきます。各章がつながりを持っていて、非常に読みやすく、集中すれば1～2日で読み終えられる内容でした。
その中で、特に印象に残った点をいくつか挙げてみます。
値オブジェクトを使ってわかりやすく安全にする
本書を読んで、自分のコードを振り返ると、string型やint型を多用しており、「このプロパティや処理が誰の責任か」が不明確になっている箇所が多いことに気付きました。例えば「金額」を表す値であれば、単なるint型ではなく、専用の「金額クラス」を作成することで、その金額に関するロジックを閉じ込め、安全で分かりやすい設計ができると感じました。
データクラスと機能クラスを分けると変更が大変
これまで、データクラスと機能クラスを安易に分けたり、サービスクラスにDB接続や業務ロジックを詰め込んでしまうことが多く、以下の問題に直面していました：
- テストが書きづらい
- 業務ロジックがどこにあるのかわからない
- 変更が広範囲に影響してしまう
本書で紹介されていたように、データクラスと機能クラスを統合した「ドメインモデル」に業務ロジックを集約し、3層アーキテクチャから分離する設計は非常に魅力的だと感じました。
業務知識とソースコードの一致が重要
業務知識をコードに反映させることの重要性についても、本書で強調されていました。その実現のために、以下のようなアプローチが有効だと感じました：
- 業務知識を事前に学ぶ
- 業務知識を持つ方の意見を丁寧に聞く
- 初期段階から業務知識をクラス設計に落とし込み、レビューを重ねる
これにより、ソースコードが「業務のマニュアル」として機能し、後からプロジェクトに参加した人にも理解しやすく、保守性も高まると感じました。
サービスクラスをシンプルに保つ
サービスクラスに業務ロジック（特にif文など）を直接書くと、次第に肥大化して見通しが悪くなることを痛感しました。たとえ1つのif文でも繰り返されることで、コードの複雑さが増していきます。
そのため、業務ロジックは適切なクラスに切り出し、サービスクラス自体をシンプルに保つことが重要だと学びました。本書で紹介されていた「サービスシナリオクラス」という手法についても、今後学んでみたいと思います。
終わりに
これまでは、サービスクラスが肥大化してくると「utilやhelperに移せばいいや」と考えることが多かったですが、本書を読んでその考えを改める必要性を強く感じました。utilやhelperは「誰の責任か」が不明確になるため、安易に使用すべきではありませんでした。
本書を通じて、設計の重要性と具体的な改善方法を学ぶことができました。これらを実務に生かし、よりわかりやすく、保守性の高いコードを書けるよう努めていきたいと思います。