2022年版実践WPF業務アプリケーションのアーキテクチャ【見積編】～ドメイン駆動設計＆Clean Architectureとともに～

見積編の構成

　さて、アーキテクチャを決定する上で、重要な2つの背景があると私は思っています。

1. ビジネスの背景
2. システム化の目的

　これらを前提としてシステム化のスコープを決定し、やっとアーキテクチャの設計がはじめられます。

　ビジネスの背景や、システム化しようとしたその背景がぼんやりしていると、アーキテクチャも、でき上がるシステムもぼんやりとしたものになってしまいます。なぜこのシステムを作らないといけないのか？ なぜそのようなシステムを作らないといけないのか？ 自分自身に、十分に説明できる状況にしましょう。

　そのため見積編としては、つぎの構成で解説していきたいと思います。

1. ビジネス背景の整理
2. システム化目的の整理
3. ビジネス全体のドメインとコンテキストの定義
4. 購買ドメインのドメインとコンテキストの定義
5. 採用技術の大枠を決定
6. 論理構成の決定
7. 物理構成の決定
8. 開発ライセンスの費用負担の決定
9. まとめ

　ここまでくると、アーキテクチャ上必要とされる費用がおおよそ明確になるでしょう。

ビジネス背景の整理

　以下は、AdventureWorksサンプルデータベースのビジネスシナリオとして公開されている文章の抜粋です。

　> AdventureWorksサンプルデータベースは、Adventure Works Cyclesという架空の大規模多国籍製造企業をベースにしています。この企業は、北米、ヨーロッパ、およびアジアのマーケットを対象に、金属製自転車や複合材製自転車の製造および販売を行っています。従業員290人の米国ワシントン州ボセルの拠点に加え、自社のマーケット基盤全体にわたって複数の地域販売チームを配置しています。

　>

　>（中略）

　>

　>Adventure Works Cyclesでは、昨年度の成功を基にマーケットシェアの拡大をねらっています。そのために、ターゲット顧客の絞り込み、外部Webサイトによる製品販売ルートの拡大、および生産コストの削減による販売コストの削減に努めています。

　*出典：Adventure Works Cyclesのビジネスシナリオ

　昨年度は大きな成果を達成しましたが、マーケットシェアの拡大をするにあたり、もっとも大切なことの1つにビジネス変革の速度を速めていくことにあると考えています。

　こういった背景のもとAdventure Works Cycles社では、販売とそれに伴う配送・製造・購買のシステムを全面的に刷新し、ビジネス目標の達成を実現します。

システム化目的の整理

　システムを刷新するにあたり、当然ながら既存システムの課題の解決が求められています。ビジネス的にシステムを刷新する目的は次の通りです。

• ビジネス変革の速度に耐えられるシステムの実現

　これを実現する上での細かな課題は多くありますが、最大の問題は全体がモノリシックな一枚岩のシステムで構成されていた点にありました。Adventure Works Cycles社全体が1つのコンテキスト（文脈）の上で設計されており、たとえば製品オブジェクトは販売・配送・製造・購買のすべての機能から共有されていました。（実際すべてのドメインがひとつのデータベース上にあります）

　その結果、販売シナリオの変更で製品オブジェクトに変更が入った場合、配送・製造・購買を含めたシステム全体へ影響が波及します。慎重に進める必要があり、多大なコストと時間がかかっていました。また想定の範囲外に影響が発生することで、頻繁に障害が発生しました。

　また、スケジュール的な問題もでてきます。2022年4月に販売機能の大幅な改修を開始しました。

　11月のブラックフライデーの目玉機能にしたいため、1カ月の余裕をもって10月には改修を終えるつもりでした。これは2022年度の販売戦略の最大の目玉でした。

　ところが8月になったところで、購買機能に急遽変更を加える必要が発生しました。しかも法令的な問題でどうしても年内に対応する必要があります。

　開発はぎりぎり12月末に完了します。ところがすでに開発を開始していた販売機能と、開発スケジュールがかぶってしまいました。10月の時点では購買機能がまだ開発中で、リリースすると購買業務が滞ってしまいます。ではリリースをまとめて12月にするかというと、11月のブラックフライデー商戦までに販売機能のリリースが間に合わなくなってしまいます。

　また、人材の育成にも問題が発生していました。システムを理解するためには、Adventure Works Cycles社のビジネスの全体を理解しなくてはなりません。それは非常に難易度が高いことです。その結果、ごく少数のエンジニアへ強く依存しており、後継となる人材を育てるめども立っていませんでした。

　これらはシステムの改修にためらいを生み、システムがビジネスに必要な変化を阻む状況となっていました。

　そこで刷新後のシステムには、全体を適切なビジネス領域ごとに分割し、それぞれが疎結合となることが求められています。ビジネス領域を適切な範囲で分割し、個別の知識領域をその範囲に限定し、個別の範囲の外へ影響がでることを最小限にします。

　分割された単位ごとに、独立したサブシステムとして構築します。ただユーザーの認証は同一の認証基盤を利用した統合認証を利用することで、セキュリティ的に難易度の高い認証基盤を個別に構築することは避けることとします。

　これにより人材の育成を促進します。また改修の範囲を限定することは開発コストの削減、リードタイムの短縮、そして品質の向上につながりますし、他の機能の改修スケジュールに影響されなくなります。その結果、ビジネスの変化に耐えられるシステムの実現を目指します。