SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

現役エンジニア直伝! 「現場」で使えるコンポーネント活用術(SPREAD)(AD)

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

ソースコード

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

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

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

前提条件

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

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

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

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

 本稿のサンプルは .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のような製品を利用することを検討してください。

次のページ
認証アーキテクチャの設計

関連リンク

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
現役エンジニア直伝! 「現場」で使えるコンポーネント活用術(SPREAD)連載記事一覧

もっと読む

この記事の著者

中村 充志(リコージャパン株式会社)(ナカムラ アツシ)

 Microsoft MVP for Visual Studio and Development Technologies リコージャパン株式会社 金融事業部 金融ソリューション開発部所属。 エンタープライズ領域での業務システム開発におけるアプリケーション アーキテクト・プログラマおよび中間管理職。 業務ではWPFおよびASP.NETを用いた業務システム開発が中心。 SI案件において、テスト・保守容易性を担保した、アーキテクチャ構築を得意としている。 GitHub:https://github.com/nuitsjp Twitter:@nuits_jp 著書 『Essential Xamarin ネイティブからクロスプラットフォームまで モバイル.NETの世界』(共著) 『Extensive Xamarin ─ひろがるXamarinの世界─』(共著)

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

提供:グレープシティ株式会社

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/17786 2023/06/15 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング