ドメイン駆動設計で実装する3つのメリット

本記事では、ドメイン駆動設計で実装する3つのメリットをお伝えします。

私は、デスクトップアプリ開発とスタンドアロンゲーム開発で、ドメイン駆動設計を採用し、実装しました。そのときにメリットとして感じたことを書きます。

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

1. 処理の場所をソースコードから特定しやすい

1つ目のメリットは、処理の場所をソースコードから特定しやすいことです。

ドメイン駆動設計は、

• インフラストラクチャレイヤ
• ユーザーインタフェイスレイヤ
• アプリケーションレイヤ
• ドメインレイヤ

など、レイヤが定義されています。ドメイン駆動設計の知識があれば、各レイヤでどのような処理をやっているか分かるはずです。

さらに、ドメインモデルを作成する過程で、パッケージ名、クラス名は洗練されて、分かりやすくなっているはずです。数十行程度のクラスファイルがフォルダ階層ごとに配置されています。

なので、フォルダの階層をたどる感覚で、処理の場所を特定できるはずです。

独自の設計手法だと、どのようにレイヤを分けられているのか？各レイヤで何をやっているのか？というところから、調査が必要です。

レイヤを特定できた後は、何千行、何万行のコードの中から特定の処理を探すことになるかもしれません。骨の折れる作業になります。

長年ソフトウェア開発の経験をやっているなら、こんな局面は1度は体験したはずです。

ソースコードの処理の場所が特定しやすいということは、不具合対応もやりやすくなります。ソフトウェアの保守性が高くなります。

2. プロジェクトメンバーに設計手法を伝えやすい

2つ目のメリットは、プロジェクトメンバーに設計手法を伝えやすいことです。

ドメイン駆動設計は、ソフトウェアの設計手法として確立されています。参考書籍もたくさん出版されていますし、ネット上にも多数の情報が記載されています。

なので、プロジェクトに新しいメンバーが入ってきたときは、

と言うことができます。ドメイン駆動設計の概要と、独自に設計したところの説明だけで、設計の説明は終わります。

と言うこともできます。

設計手法で質問があったときも、ドメイン駆動設計の手法を利用して説明できます。

一方、独自の設計手法を使用すると、新しいプロジェクトメンバーの設計手法を1から説明する必要があります。説明に時間がかかります。

説明なしで、いきなりソースコードを読んでもらう場合でも、設計手法が確立されているドメイン駆動設計のコードのほうが、短時間でコードを理解できるでしょう。

独自の設計手法において、あなたしか設計手法を理解していない場合は気をつけなければいけません。時間が経つにつれて、あなたも設計手法を忘れていくからです。設計書はメンテナンスしておきましょう。

3. 不具合が発生しにくい

3つ目のメリットは、不具合が発生しにくいことです。

ドメイン駆動設計は、モデリングを繰り返しながら、ユビキタス言語を考慮しつつ、ソフトウェアを作成していきます。その過程で、クラス名、パッケージ名が分かりやすく抽象化されます。名前を見ただけで、何をするクラスなのかが分かります。

1つのクラスが何千行、何万行となっていることはなく、if文の巨大なネストもないはずです。

なので、不具合が発生しにくいです。仮に不具合があったとしても、ソースコードの処理の場所を特定しやすいので、不具合の原因となっている場所を見つけやすいです。

少なくとも、何千行、何万行もあるコードよりは不具合は発生しにくいです。

まとめ

本記事では、ドメイン駆動設計の3つのメリットをお伝えしました。

ドメイン駆動設計を採用することで保守性の高いソフトウェアを作成することができます。

といっても、ドメイン駆動設計にもデメリットはあります。デメリットについては↓の記事を参考にしてください。