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

　前回記事では、初期のドメインビュー・ユースケースビューから、アーキテクチャを設計していくための土台となる初期の論理ビュー・実装ビュー・配置ビュー・データビュー・プロセスビューの設計を行い、全体の大まかな設計を行いました。その結果、個別の非機能要件やユースケースを個別に設計できる状態になりました。そこで今回は、ユースケースを設計する前に事前に設計しておいたほうが非機能要件について設計を進めます。具体的には認証・例外・ロギングのアーキテクチャです。これらはユースケースの設計に影響を与えたり、設計に応じた仮実装を進める上で、事前に決められていたほうが扱いやすい要素だからです。

ソースコード

　実際に動作するソースコードは、GitHub上に公開しているので、ぜひご覧ください。ビルドや実行方法については、リンク先のREADME.mdをご覧ください。また、実際に動作させるためには次の2つのライセンスが必要です。

• ComponentOne for WPF
• SPREAD for WPF 4.0J

　これらは試用ライセンスを発行することができます。

　本稿だけで読み進められるように記載していますが、すべてのコードを詳細に解説しているわけではありません。本稿を読んだ後、あらためて動作させつつコードと本稿を読み比べていただければ、理解が深まるかと思います。

前提条件

　本稿はWPFアプリケーションのアーキテクチャ設計について記載したものです。すでに公開されている「見積編」および「設計編／前編」が前提となります。未読なものがあれば、そちらからまずはお読みください。

　本稿にはサーバーサイドの設計も一部含まれていますが、見積編にも記載した通り、サーバーサイドについてはWPFアプリケーションを設計する上で、必要最低限の範囲に限定しています。サーバーサイドの実現方式は、オンプレ環境なのかクラウド環境なのか？ といった容易さなどで大きく変わってきます。そしてWPFアプリケーションから見た場合には本質的な問題ではありません。サーバーサイドまで厳密に記載すると話が発散し過ぎてしまい、WPFアプリケーションのアーキテクチャにフォーカスすることが難しくなるため、あくまで参考程度にご覧ください。

　また本稿ではAdventureWorks社の業務のうち、発注業務システムのアーキテクチャとなります。特定業務は発注業務に限定されますが、認証などの複数の業務にまたがったアーキテクチャの実現についても言及しています。

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

• 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
• ドメイン駆動設計（DDD）

　Clean Architectureについては、筆者のブログである「世界一わかりやすいClean Architecture」をあわせて読んでいただけると、本稿のアーキテクチャの設計意図が伝わりやすいかと思います。

　ドメイン駆動設計の適用範囲については、本文内でも、つど解説いたします。

本稿の構成

　本章では非機能要件の中でも需要が高く、設計初期に共通で実施しておく必要のあるつぎの3つの非機能要件を例に、アーキテクチャを設計します。

1. 認証アーキテクチャ
2. 例外処理アーキテクチャ
3. ロギングアーキテクチャ

　ログ出力をする場合、一般的に利用者情報を付加することが多いと思います。そのため、先に認証処理を実現するとむだが少ないため、先に認証処理の設計を行うこととします。

認証アーキテクチャの注意点

　インターネットのように広く公開するサービスの場合は、適切な認証プロバイダーを選定してください。

　本稿では、実際に皆さんにコードを動かしていただくことを想定して、外部サービスを利用しないで実現する方式を選定しています。企業内ネットワークのような限定された環境では必要十分な設計だと思いますが、オープンに公開するためには認証機能を独自開発するようなリスクは避けるべきでしょう。また仮に企業内ネットワークであっても、ほかに利用できる認証プロバイダーがあるのであれば、そちらの利用をご検討ください。

　例えば、Azure Active Directoryのような製品を利用することを検討してください。