11-ドメインの言葉を使ったコード

「プログラマが知るべき97のこと」の11個目のエピソードは、ドメインモデルの話です。「ドメイン」は、プログラミングを勉強している中で遭遇するちょっと意味のわかりにくい横文字の１つです。日本語訳すると「分野」とか「領域」等になりますが、しっくりこないのでドメインとカタカナで表されます。ドメインモデルとはWikipediaによれば「システムに関わる様々な実体とそれらの関係を説明するシステムの概念モデル」と書かれていますが、それほど難しいものではありません。要はシステム内で何らかの意味を持ったカタマリの事で、実装上はクラスに近い関係です。ドメインモデルは概念上のもので、幾つかのクラスでドメインモデルが構成されます。１ドメインモデル＝１クラスのこともありますが、リファクタリングにより分割されることもあるでしょう。尚、クラスの責務を最小限にしていれば、異なるドメインで同じクラスになることはほとんどありません。
このエピソードでは、ドメインモデルを意識したコードを書くべきという事が語られています。言い換えると、業務ルールをそのままロジックに落としたコードは避けるべきという事です。業務ロジックの仕様のままコードに書いてしまうと、一見で理解できない本文にあるようなコードが生まれます。しかし、「コードがどのような概念を表しているのか、できる限り一目でわかるようにしておくべきです。」
ドメインモデルを知らなくとも、このようなケースではメソッドの抽出というリファクタリングで意味のある名前のメソッドを作成します。ここで何度も同じオブジェクトの状態を取得している所に着目して、クラスへの抽出（移動）のリファクタリングを行います。これが本文で示されているドメインモデルのコードです。つまり、トレーダーの状態を判定してサービスクラスがアクセス件を持つかを判定するのではなく、トレーダーにアクセス件の有無を問い合わせる形です。これを続けていけば、そのドメインに関するコードは対応するドメインクラスに集約されていき、ロジックはカプセル化され、修正の影響範囲も特定しやすくなります。
重要なのはドメインクラスを重視することではなく、ドメインクラスを使った書き方を知り、必要な場合に適切なメソッドの移動が可能なことです。あるクラスの状態を幾つか判定して特定の条件とするコードがあったならば、そのコードはそのクラスに移動しましょう。また、ドメインクラスが良いと言ってもやりすぎると「共有は慎重に」と同じ問題を引き起こします。メソッドの抽出で止めることも大切です。

プログラマが知るべき97のこと