【ITニュース解説】Applying Domain-Driven Design to Problem Design and Project Management

DDD（ドメイン駆動設計）は、ソフトウェア開発においてビジネスの「ドメイン」、つまりそのビジネス特有の業務知識や概念を深く理解し、それをソフトウェアの設計に反映させる手法である。多くの開発者は、DDDをユビキタス言語（ビジネス関係者と開発者の間で共通の言葉を使うこと）や、境界づけられたコンテキスト（システムの特定の領域に特化したモデルを構築すること）といった概念を通じて理解し、ビジネスの専門家と協力しながら開発を進めるものだと捉えているかもしれない。しかし、この記事では、DDDが単なる開発手法にとどまらず、プロジェクトにおける「問題」そのものを設計し、要件を詳細に検討する段階、さらにはプロジェクト管理の段階でどのように役立つかについて、非常に興味深い視点を提供している。

私たちがシステムを開発する際、まずその対象となるビジネス領域、すなわちドメインを理解する必要がある。例えば、病院のシステムを考える場合、何の知識も持たずに見ると、システムを利用する「ユーザー」は単に「患者」だけだと考えてしまうかもしれない。しかし、実際に病院の業務を深く掘り下げ、ドメインの専門家と対話してみると、ユーザーの立場や役割が、システムとの関わり方によって大きく変わることが見えてくる。

具体的に見てみよう。病院を訪れたばかりの人は、受付で対応を受ける間は「顧客」という立場になる。登録を済ませ、医師の診察を待つ間は「患者」である。診察や治療が終わり、会計窓口にいる時点では、まだ支払いをしていないため「債務者」となる。そして、支払いを終えて処方箋を受け取るために待っている間は「処方箋受取人」となる。このように、一人の人間が病院の中で移動し、さまざまなサービスを受けるたびに、その役割やビジネス上の意味合いが変化していくのだ。

このドメイン知識を適用することで、私たちはシステム全体を漠然と捉えるのではなく、より明確なサブシステムに分割できることがわかる。 受付で対応する「顧客」の側面は、CRM（顧客関係管理）システムとして捉えられる。 診察や治療を受ける「患者」の側面は、医療記録システムとして、これは病院の「核となる業務」であるため、コアなドメインと位置づけられる。 会計を行う「債務者」の側面は、財務システムの一部となる。 処方箋を受け取る「処方箋受取人」の側面は、薬局の在庫管理システムを利用することになる。

もしこれらのサブシステムを分解せず、すべての業務を「病院システム」という一つの大きな塊として捉えてしまうと、どのような問題が起こるだろうか。例えば、「患者」に関する情報を一つの大きなデータベーステーブルにまとめようとすると、そのテーブルは「顧客」としての情報、「患者」としての情報、「債務者」としての情報、「処方箋受取人」としての情報が混在し、非常に肥大化したものになってしまう。それぞれの情報が持つ意味合いも曖昧になり、特定のビジネスプロセスに対応する際も、必要ない情報まで読み込んだり、複雑な条件分岐が必要になったりする。結果として、システムの設計は複雑化し、変更に弱く、保守が困難になる可能性が高まるのだ。

さらにこの記事では、DDDの戦略的設計の考え方を応用し、問題を「ドメイン」と「サブドメイン」に分類することで、より効果的な解決策を導き出す方法を提示している。ドメインを次のように再分類するのだ。 コアドメイン: そのビジネスにとって最も重要で、競争力の源泉となる中核的な業務領域。病院の例で言えば、医療記録システムがこれにあたる。 汎用サブドメイン: どんなビジネスにも共通して必要とされる機能領域。例えば、CRMや財務システムは、病院だけでなく、多くの企業で必要とされる。 支援サブドメイン: コアドメインを支えるために必要だが、それ自体がビジネスの中核ではない領域。薬局の在庫管理システムなどがこれに該当する。

このように問題を分類すると、それぞれのドメイン特性に応じた最適な解決策を適用できるようになる。 例えば、もしチームに人手不足の問題がある場合、この分類は非常に有効な指針となる。 コアドメイン、つまり医療記録のような中核業務に対しては、その分野の専門知識を組織内に留め、競争力を維持するためにも、社内の優秀な人材を投入し、最大限のリソースを割り当てるべきだ。これは、自社の強みを最大限に活かし、他社との差別化を図る上で不可欠な部分である。

一方、汎用サブドメインであるCRMや財務システムについては、「構築するよりも購入する」という原則に従うことが賢明だとされている。これらの領域は多くのビジネスで共通して使われるため、すでに市場には優れた既製製品が多数存在する。自社でゼロから開発するよりも、これらの専門製品を導入することで、開発にかかる時間やコストを大幅に削減できる。また、自社があまり得意としない領域に貴重なリソースを浪費せずに済み、その領域の専門家が開発した高品質なソリューションを享受できるというメリットもある。場合によっては、その分野に特化したベンダーにプロジェクト管理を委託する選択肢も有効だ。

最後に支援サブドメイン、例えば薬局の在庫管理システムのような領域は、コアドメインほどではないものの、やはり重要な役割を担っている。この場合、限られた社内メンバー（例えば2人）を割り当てつつ、信頼できる外部パートナーと「タイム＆マテリアル（T&M）」契約を結び、協力して開発を進める方法が考えられる。これにより、必要な機能を効率的に実装しながら、社内リソースをコアドメインに集中させることが可能になる。

このように、問題を単一の大きな塊として捉えるのではなく、DDDの考え方を用いて細かく分割し、それぞれの特性を理解することで、各部分に対する要件が劇的に明確になる。そして、その明確になった要件に基づいて、人員、時間、予算といったリソースを最も効果的な方法で割り当てることができるようになるのだ。

開発者としての経験からも、ビジネスニーズを真に理解することで、多くの問題がはるかに簡単に解決できることが実感できる。時にはコードを書かずとも、適切な戦略と資源配分だけで解決できる問題も少なくない。DDDは単なるコードの設計手法ではなく、問題の発見から解決、そしてプロジェクト全体を成功に導くための強力な思考フレームワークとして、システムエンジニアを目指す初心者にとっても非常に有用な視点を提供してくれるだろう。