【ドメイン駆動設計】Serviceをクラス名で使わない

本記事では、ドメイン駆動設計 ドメインサービスにおいてServiceをクラス名で使わないというテーマで書きます。

タイトル通り、クラス名に、Serviceと入れない方がいいです。

その代わり、何の処理をするか分かるクラス名とすべきです。

Serviceをクラス名で使わない

DDD本では、ドメインサービスにおいて、〇〇〇Serviceというクラス名が登場します。

しかし、以下の理由から、Serviceをクラス名で使わないほうがいいです。

何をするクラスか分かりにくい

〇〇〇Serviceというクラスは、クラス名を見ただけでは、何をするクラスか分かりません。

ドメイン駆動設計において、Factory、Repository という言葉も出てきます。これらは、クラス名を見ただけで、何をするクラスか分かります。

Factory	オブジェクトを生成するクラス
Repository	データベース、ファイルシステムのアクセス

いろんな処理を追加してしまう

Serviceという名前は、何の処理でも行うイメージがあります。

別のプログラマーがServiceクラスに新しい処理を追加するかもしれません。

その結果、Serviceクラスにいろんな処理が混ざりすぎて、共通( Common ) クラスのようになってしまいます。

やりたい処理を見つけにくいと、そのクラスを使わなくなって、そのクラスでやってる処理を別のクラスに実装してしまいます。

Serviceクラスが共通クラスのようにならないために、クラス名にServiceを入れないようにします。

ドメインサービスを使用してはいけないと言ってるわけではありません。状況によっては、ドメインサービスを使ったほうが分かりやすくなることはよくあります。ただ、ドメインサービスを使うとき、Serviceというクラス名は使わないようにします。

何の処理をするか分かる名前のクラスを使う

Serviceという名前を使わない代わりに、Factory、Repositoryのように、クラス名を見ただけで何の処理をしているか分かる名前にすべきです。

ぼくは、以下のような名前のクラスを使用しています。

代わりのクラス名	クラスでやること
Calculator	計算をする
Referee	判定を行う
Designer	描画を行う

クラス名を見て、何の処理をするクラスか分かると思います。

Calculator クラスに、描画処理を入れる人はいないでしょう。

まとめ

ドメイン駆動設計 ドメインサービスにおいてServiceをクラス名で使わないというテーマで書きました。

クラス名でServiceという名前は使わないほうがいいです。

その代わり、何の処理をするか分かるクラス名とすべきです。

以下の書籍を参考にしています。