ビジネス全体のドメインとコンテキストの定義
さて、ではAdventure Works Cycles社のビジネス領域を実際に分割していきましょう。この際に有効なのがドメイン駆動設計の「境界付けられたコンテキスト」です。ビジネス全体を関連するドメインとコンテキストに分割します。
ドメインとは何らかの問題領域のことで、ビジネスにおける感心の単位と言っても良いでしょう。ドメインには、ドメインを表現するコンテキスト（文脈）が含まれます。コンテキストにはそのドメインを表現する名前や振る舞い（つまりオブジェクト）が定義されます。
では実際にドメインとコンテキストを図示してみましょう。
図は何を書いても良いのですが、今回はUMLのケースツールを利用しました。ドメインをパッケージで、コンテキストをコンポーネントで表しています。コンポーネント間に依存関係が引かれていますが、どちらのコンテキストが上流で、どちらが下流かを矢印で表しています。矢印が向かっている先が上流です。
ドメイン駆動設計で構築されていないレガシーなシステムが混じると、ドメイン：コンテキストは1：1にならないケースもあります。今回は全体を新規で作成するため1：1に定義しています。
全体を販売・配送・製造・購買・認証の5つのドメインとそれぞれのコンテキストに分割しています。これらのドメインをコア・支援・汎用に分類します。ビジネスの中心となる「コア」ドメインはもちろん販売ドメインでしょう。販売コンテキストでは、顧客や製品、その在庫を定義します。
配送・製造・購買のドメインは販売ドメインを「支援」するドメインとします。販売を支援するため、それぞれ配送・製造・購買業務を実現し、それらに必要となるオブジェクトをそれぞれのコンテキストで定義します。これらのシステムを利用するにあたり、従業員は統合認証機能を利用します。そのため統合認証は「汎用」ドメインとして扱うのが良さそうです。
このように全体をドメインごとに分割することで、興味の範囲を限定できます。これで、いずれかのドメインの改修が別のドメインに影響するリスクをさげることができますし、それぞれの開発スケジュールに制約されることもなくなります。開発者も単一のドメインに集中することができて、人を育成する難易度も下がります。もちろん、それは設計や実装に大きく依存します。そのあたりは今後詳細に説明します。
これは必ずしもシステム的な側面で重要なだけではありません。
システムを開発していく際には、当然実際の業務に詳しい「ドメインスペシャリスト」と協業して構築していくことになります。このとき、すべてのドメインに詳しいドメインスペシャリストが存在することはなかなか期待できません。もちろんそういった人が存在することもありますが、きっととても多忙な人です。システム全体の開発がその人に依存した場合、容易にボトルネックになることが想像できます。その人が病気で倒れたら全体の開発がとん挫するでしょう。
しかしドメインが分割されていれば、リスクを大きく下げることが可能です。全体を理解している人は、全体のコラボレーションだけに注力し、個別のドメインは、ドメイン別のスペシャリストを配置すればよいのです。
業務の視点でドメイン分割することで、モノリシックな構造で構築した場合の多くの課題を解消できます。これでAdventure Works Cycles社の全体最適な「境界付けられたコンテキスト」が明確になりました。
購買ドメインのドメインとコンテキストの定義
さて、全体の「境界付けられたコンテキスト」は定義されました。
ただ本稿ですべてのドメインを対象とするのはさすがに広すぎます。そのため本稿では購買コンテキストの一部の機能を対象とします。では購買コンテキストに焦点をあてて「境界付けられたコンテキスト」を再定義します。
先ほど検討したものは全社最適なモデルでした。ここから購買に焦点をあてて分析・設計していく場合、当然購買コンテキスト中心の「境界付けられたコンテキスト」を定義する必要があります。
これにはおもに2つの理由があります。
- 全社モデルではスコープが広すぎて、複雑かつ大きすぎる
- 同一の企業であっても、焦点のあたっているコンテキストによって見え方は異なる
たとえば、販売コンテキストには「製品」が含まれます。しかし、販売コンテキストにとっての「製品」と、購買コンテキストから見た「製品」は大きく異なります。販売コンテキストのほうがより詳細に「製品」のことに興味があるでしょう。それでも販売コンテキストはたとえば、その「製品」を優先的に購入すべきベンダーがどこかといった情報には興味はないでしょう。
視点によって境界付けられたコンテキストを再定義することで、感心の範囲を必要な範囲に限定し、理解を促進します。その結果、影響範囲を限定することで生産性や品質が向上するでしょう。
では再定義した境界付けられたコンテキストを見てみましょう。
2カ所変更が入りました。
- 購買ドメインがコアドメインに、販売ドメインが支援ドメインに変更された
- 配送ドメインが削除された
いま分析・設計しているのは購買ドメインです。そのためAdventure Works Cycles社を購買ドメインの視点で俯瞰します。
このとき視点の中心にくるのはあくまでも購買ドメインです。購買ドメインをどのように実現するのか？ が中心で、それ以外のドメインは購買ドメインとどのような関係にあるのか整理します。そのため購買ドメインがコアとなり、販売ドメインは支援となります。
また購買ドメインは、配送ドメインに特定の興味がないため削除しています。
採用技術の大枠を決定
購買ドメインの境界付けられたコンテキストが完成しました。ではいよいよ技術的な選定にはいりましょう。
端的にいうと、フロントエンドとバックエンドを何でつくるか決めます。今回はつぎの理由からフロントもバックエンドも .NETで統一し、フロントエンドはWPFを用いて開発することとします。
- 開発者が .NETの開発に習熟しており、十分な開発経験がある
- WPFの開発をリードできるエンジニアが存在している
- フロントとバックエンドを .NETで統一することができる
- フロントエンドのアーキテクチャが安定的であり、ビジネスにフォーカスできる
- .NETのエコシステムは十分に成熟しており、高い生産性・品質が期待できる
私の個人的な経験ではWPFを選定したプロジェクトでは、周辺デバイスと密接に関連したアプリケーションであったり、マルチディスプレイ前提でマルチウィンドウアプリケーションとすることで、業務の生産性を高められるアプリケーションなどでWPFを採用してきました。
またSPAのようなモダンなフロントエンドは、現時点でもアーキテクチャ的な安定度でいうとWPFに一歩劣ると思っています。長期的な安定度でいうとWPFが有利だと思います。ビジネスの変化へ追随するため、機能の改修にフォーカスし、フレームワークからの影響をさげるという意味でWPFを選択するのは十分に現実的です。
業務アプリケーションという観点で、SPAで作れて、WPFでは作れないものは通常考えにくいことも理由になるのではないでしょうか。
