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

　現在、ドメイン駆動設計やClean Architectureなどが日本でも良く語られるようになり、広く受け入れられはじめています。技術的にはWindows Presentation Foundation（以下WPF）も .NET Frameworkだけでなく .NET上でも動作するようになりました。筆者もそれらを取り入れて開発しています。本稿ではマイクロソフトが架空の大規模多国籍製造企業を想定し公開している、サンプルデータベース「AdventureWorks」を題材に、グレープシティのコンポーネント「ComponentOne for WPF」や「SPREAD for WPF」を活用して業務アプリケーション開発をする際のアーキテクチャを紹介します。

はじめに

　さて、タイトルをみて疑問を持った方もいらっしゃるのではないでしょうか。「見積編？」と。

　2018年4月に書いた「実践WPF業務アプリケーションのアーキテクチャ」に決定的に欠けていた視点がありました。

　それはClean Architectureでも、DDDでもなければ .NET 6でもありません。これらのアーキテクチャは今後も変わり続けていきます。それは欠けた視点ではなく、結論のない、より良いアーキテクチャを追求し続けた結果の変化でしかありません。

　決定的に欠けていたのは、プロジェクト開始前にアーキテクチャ的にどのようなことを検討しなくてはならないか？ という視点です。これは普遍的に必要なものです。

　受託開発のようなプロジェクトであれば当然ですが、自社開発プロダクトであっても、計画時に仮説として採算計画を必ず立てます。ソフトウェア開発における自由度がもっとも高い時点は、予算が決定する前です。逆に言うと予算が決定されてしまうと、有償ツールや有償コンポーネント1つ買うのも苦労します。

　アーキテクトの仕事は、アーキテクチャを決定することですが、自由にアーキテクチャを決定するためには、自由な採算が必要です。採算的裁量がもっとも高いのは、間違いなく予算決定前です。

　しかし当然予算決定前というのは、要求がもっとも曖昧な時期です。その時点で厳密なアーキテクチャを決定することはできません。しかし予算は決めなくてはいけません。アーキテクチャなどの点を、どのように検討・決定したらいいのでしょうか。

　それとは別に、前回からこれまでの間に浸透してきたClean ArchitectureやDDDと、WPFでどのように付き合うのが好ましいかも触れていきたいと思います。

　また .NETの技術的な点で大きな変化のひとつにGeneric Hostの普及があります。これはクラウド開発が起点になっているもので、近年のモダンな .NET向けフレームワークやライブラリはGeneric Hostを前提としたものが増えてきています。WPFアプリケーションもGeneric Host上に開発することで、これらの恩恵を最大限活用できます。

　本稿はそういった観点から、予算の決定される見積時から、プロジェクトが開始された後の具体的な設計時・実装時のアーキテクチャまでプロジェクトライフサイクル全体を通して、アーキテクチャをどのように検討していったらよいか？ その1つの案を提案いたします。

　本稿が、アプリケーションを構築する上でのアーキテクチャについて、悩んでいる人へのヒントになれば幸いです。なお、ここでいうアーキテクチャとは、ソフトウェア開発における技術的な重大な決定事項のすべてを指します。

本稿の内容について

　本稿では、Microsoft社が公開しているSQL Serverのサンプルデータベース「AdventureWorks」を参考に、WPFで業務アプリケーションを構築するためのアーキテクチャを解説します。

　AdventureWorksは販売・配送・製造・購買という、Adventure Works Cycles社のビジネス全体を対象としています。本稿ではこのうち、購買にスコープをあてて解説します。

　アーキテクチャ的に、とくに重要なポイントとして下記の採用があります。

1. ドメイン駆動設計（以降DDD）
2. Clean Architecture
3. Generic Hostの採用
4. WPFの継続的インテグレーション（CI）におけるUI自動テスト

　本当はCDにも踏み込みたいのですが、WPFが採用されたプロダクトのCDについて私も現時点で試行錯誤中です。そのうち皆さんとお話しできる日を夢見つつ、今回は除外させていただきました。

　本稿では、WPFでアプリケーションを構築する場合に、どのように要素を分解し、どう結合していくのか。アプリケーション構築時の大きな枠組みを中心に記載します。そのため下記の内容については、サンプルとして一部実装されていますが主眼に置かれていません。

1. 各種コンポーネントの詳細な利用方法
2. バックエンドのアーキテクチャや実装

　特に後者については、WPF自体とは直接関連性がありません。近年の業務アプリケーションでもクラウドファーストが浸透してきているのを感じますが、クラウド上で本稿のサンプルを動作させようとした場合、WPFと関係性の薄いバックグラウンドをクラウドで動かすための説明が増えてしまいます。そこでサンプル上はクライアント・Web API・データベースの一般的な3層アーキテクチャとします。クラウドの知識が十分にあれば、応用してクラウドへシフトすることは難しくないでしょう。

前提条件

　本稿は以下の環境を前提に記載しています。

• Visual Studio 2022 Version 17.4.0
• Docker Desktop 4.14.0
• Docker version 20.10.20
• SQL Server 2022-latest(on Docker)
• ComponentOne for WPF
• SPREAD for WPF 4.0J
• Test Assistant Pro 1.123
• .NET 6.0.11

　本稿のサンプルは .NET 6で構築しますが、.NET Framework 4.6.2以上（.NET Standard 2.0水準以上）であれば同様のアーキテクチャで実現可能です。ただし一部利用しているパッケージのバージョンを当てなおす必要があるかもしれません。

想定読者

　次の技術要素の基本をある程度理解していることを想定しています。

• C#
• WPF
• Docker
• SQL Server

　これらの基本的な解説は、本稿では割愛しますが、知らないと理解できない訳でもありません。また下記の2つも概要が理解できていることが好ましいです。

• Clean Architecture
• ドメイン駆動設計

　Clean Architectureについては、筆者のブログである「世界一わかりやすいClean Architecture」をあわせて読んでいただけると、本稿のアーキテクチャの設計意図が伝わりやすいかと思います。ドメイン駆動設計の適用範囲については、本文内でも都度解説いたします。