はじめに
本シリーズでは、DDD（ドメイン駆動設計）について僕が学んだことを複数回に分けて紹介していきます。
本記事ではDDDの個別具体的な実装方法には触れずに、DDDを使いたくなる気持ちにフォーカスして理解したいという目的で書かれています。
対象読者
- DDDを始めて学ぶ人
- DDDについて学んでいるが、いまいち効果を感じられていない人
に向けて書かれています。
競争に勝つために
ソフトウェアは世の複雑な課題を解決します。数多の企業が知恵を絞ってユーザー体験の向上に日夜取り組んでいます。明日使われるソフトウェアは今日のユーザー獲得競争に生き残ったソフトウェアです。つまり、
より多くのユーザーを獲得し、競合との競争に勝つこと
が、近視眼的には、ソフトウェアを開発する人、企業が考えるべき最大の課題です。どれだけ高級なアルゴリズムを使っていても、ユーザーが使わないソフトウェアに市場価値はつきません。
ソフトウェアの複雑性
世の中には面倒な業務がたくさんあります。
例えば、家計管理 という業務を考えてみましょう。
- 領収書の整理や入力
- 毎月の固定費の計上
- 複数口座の管理
どれも煩雑で、できればやりたくありませんよね。
ここで これらをコンピュータにやらせたい！ と考えるのは、現代を生きる我々にとって自然な発想です。
ソフトウェアが解決すべきことは複雑であるべきです。誤解を恐れずに言うと、複雑であればあるほど良いと言っても過言ではありません。なぜならば、複雑な課題であればあるほど、参入障壁が高くなり競合の数を減らせるからです。
仮に、この家計管理を解決するソフトウェアでできることが、領収書を入力し、合計を計算して画面に表示するだけのものであれば、簡単なCRUDアプリケーションで実装できます。しかし、すぐに競合に真似されてしまうでしょう。このソフトウェアが生き残るためにはもっと複雑な業務ロジックを含む必要があります。実際、世で多くのユーザーを獲得しているアプリは全て複雑な業務ロジックを含んでいます。
ソフトウェアの複雑性とDDD
では、この複雑性をどのように管理すれば良いでしょうか。ここでドメイン駆動設計の考え方が重要になってきます。
純粋なOOPの問題点
オブジェクト指向型プログラミング(OOP)は業務をクラスで表現するという強力な手法ですが、思想のないOOPで複雑なロジックを表現しようとすると以下のような問題が生じます。
- 責務が分散してしまう
- モデルが巨大になってしまう
これらは、僕のような初学者にありがちな失敗で、OOPを学んだばかりの人がよくやってしまうことです。 こうなってしまっては新しく機能を追加する際にも、どこまで変更の影響が波及するか特定が困難になり、仕様変更が難しくなります。ソフトウェアが柔軟でないと言うことはより良いユーザー体験の追求を妨げることになり、競争に勝つことができなくなります。
DDDはこのような問題が起きないためにOOPを規定する設計思想です。
注 DDDはOOPだけでなく、関数型プログラミング(FP)にも適用できます。
ドメイン駆動設計の気持ち
DDD（ドメイン駆動設計）を学ぶとき、多くの人は 「DDDとは何か？」 を知ろうとします。しかし、本当に大切なのは 「なぜDDDを使いたくなるのか？」 という感覚を持つことです。
OOPを学んだとき、クラスで世界を表現できるという考えにワクワクした経験はありませんか？
関数型プログラミング（FP）を知ったとき、副作用のない関数の美しさに魅了されたことは？
DDDはその延長線上にあります。
現実の業務（ドメイン）をクラスやオブジェクトで整理し、その変化に適応できる設計を作る。
これは、ただの技術論ではなく、ソフトウェアをより良いものにするための思想です。
DDDを学ぶと何が嬉しいのか
DDDは、ただの設計手法ではありません。
「なんとなくOOPを使って設計したら上手くいかなかった」という経験をした人たちが、試行錯誤の末に生み出した 「設計の哲学」 です。
DDDを知れば、ただコードを書くのではなく、ソフトウェアを通じてビジネスの本質を捉え、変化に強い仕組みを作る という気持ちが芽生えます。
まとめ
本記事では、DDDを学ぶ動機について説明しました。要点は以下の通りです：
- ソフトウェアは複雑な課題を解決し、競争に勝つ必要がある
- 複雑性は避けるべきものではなく、むしろ競争優位性を生む
- 単純なOOPでは複雑性の管理が難しい
- DDDは複雑性を管理するための設計思想である
- DDDを学ぶことで、ビジネスの本質を捉え、変化に強いソフトウェアを作る視点が得られる
次回は、具体的な実装例として 「じゃんけんアプリで学ぶDDD」 です。シンプルな例を通じて、DDDの実践的な適用方法を見ていきましょう。