論理構成の決定
さてフロントもバックエンドも .NETで作ることが決まったら、つぎに考えるのはシステム全体の論理構成です。物理的な配置モデルではなく、どのような役割が必要となるか整理した論理モデルを作成します。
まずはノードのみをある程度プロットし、ノード上に必要な要素を抽出しながら整理していくのが個人的には分かりやすいと思っています。UMLの配置図を利用して図示してみましょう。
購買ドメインですが、クライアント・Web API・データベースの一般的な三層モデルとしています。最初に記載した通り、バックエンドはWeb APIで提供しますが、具体的な実行環境などの詳細は本稿では規定しません。
本稿のスコープは購買ドメインですので、認証・販売・製造ドメインは単一の論理ノードとして抽象化して捕らえます。実際には購買ドメインのように細分化されたノードが存在します。「境界付けられたコンテキスト」でドメインとコンテキストを分離しているので、他のドメインについて、そこまで踏み込む必要はありません。
さて現在検討中のアーキテクチャは、予算決定のためのアーキテクチャです。そのために必要で、現時点で欠けている視点があります。
それは開発環境におけるアーキテクチャです。アーキテクチャとは、先に述べたように「ソフトウェア開発における重大な決定事項のすべて」です。開発環境は重大な決定事項ですし、開発環境にも当然お金がかかります。金銭的な支出は早い段階であればあるほど容易で、後半に行くほど困難になります。
具体的になにを考慮する必要があるでしょう？ 個人の開発端末、ソースコードを管理するバージョン管理システム、CI環境。CIを考えたとき、UIテストの実行環境はどうするべきでしょうか？
多少の相違はあれど、概ね次のようになるでしょう。
WPFでUIの自動テストを考慮した場合、ユーザープロセスでテストエージェントを実行する必要があります。そこでCIノードとは別にテストエージェントホストをノードとして記載しています。
なお実際には文書を管理するサービスや、コミュニケーション用のメールやチャットサービスなども必要です。既存のものを利用する場合でも本来は記載したほうが良いのですが、WPFから乖離しすぎるため本稿ではそれらは除外します。むしろそのあたりの選定は、プロジェクトマネジメントの視点の方が重要になる側面もあります。
また、予算決定のためのアーキテクチャですので、たとえば費用の発生しないOSSライブラリなどは記載しなくてかまいません。むしろ個人的な経験としては、そこを考え始めると楽しくて時間を溶かしてしまうので、この時点ではあえて記載しないほうが良いとも思っています。
逆に有償のライブラリは、この時点で必ず含めておきましょう。
個人的には一定規模の業務アプリケーションを作る場合、有償のUIコンポーネントは必須と考えています。業務アプリでは列数の多いグリッドが多用されます。その際に一覧のソート・フィルタリング・グルーピングなどの機能があると業務上非常に便利です。たとえば購買状況を任意のグループで集計して分析したり、同一列で複数のAND・OR条件でフィルタリングしたり。開発時には想定できなかった運用上の問題を解決できることも多いでしょう。
これらは業務システムの個別開発として実装するには、コスト的に現実味がありません。グリッド以外にも検索可能なドロップダウンや日付関連コントロール、ドックなどのレイアウト機能もあると同じ開発コストで提供できる価値が大幅に向上します。業務アプリケーションを構築するのであれば、この時点で統合コントロールパッケージは費用に含めておくべきです。
WPFのユーザーコントロールを提供しているベンダーは多数あります。機能的に必須なものがあって、選択の余地がない場合を除き、ベンダー選定は非常に悩みます。そこで簡単な指針を示したいと思います。開発チームがグローバルで全員が英語に十分に馴染んでいる場合を除き、日本語でダイレクトなサポートを得られる製品を選ぶと良いでしょう。
有償コントロールの使い方が分からない、意図しない挙動が発生するといった場合、たとえばWPFの標準機能のように検索すれば解決できるとは限りません。その際に開発会社の直接サポートは必須です。グローバルなチームでなければ日本語のサポートが好ましいでしょう。そのため国内企業か、開発企業の日本法人のある会社を選ぶことを強くオススメします。もちろん唯一性の高いコンポーネントが国内にない場合を除きます。その際は日本語サポートを提供してくれる開発ツールに馴染んだ代理店を選定すると良いでしょう。一般的な商社経由はオススメできません。
今回のサンプルでは下記のコンポーネントを利用することとします。
ComponentOneはWPF向けの多機能な統合パッケージです。デザインを統一する意味でも基本的なコントロールはComponentOneにがっつり依存して実装します。WPFの標準コントロールはあまりに素っ気なさ過ぎますが、業務システムで本格的にデザイナーに参加いただくことは難しいでしょう。OSSのテーマも存在しますが、業務用としてみるとコントロールが不十分で、十分なコントロールを寄せ集めるとデザインがちぐはぐになるか、デザインを統一するのに大きなコストが必要となります。統合パッケージのテーマにがっつり依存して、使い勝手がよく統一されたデザインのもとに開発するのが最善だと実感しています。
SPREADは高度なレイアウトが実現できるグリッド・スプレッドシートコンポーネントです。業務システムの場合、多段やグループ集計などの柔軟な表レイアウトが、求められることがあります。SPREADを利用することでそういった要求に応えることが可能になるでしょう。ちょっと同等のものを自作することは考えられないレベルです。
ではこれらのノードの上に配置する要素をコンポーネントとしてプロットしていきましょう。
たとえばクライアント上にはもちろんWPFで開発された購買アプリが配置されますし、WPFアプリを動作させる .NETのランタイムも必要でしょう。開発端末の上にはVisual Studioが必要でしょうし、バージョン管理をGitでするのであればバージョン管理ノード上にはGitを提供できるサービスが配置されているでしょう。実際にプロットしてみましょう。
ざっとこんな感じでしょうか？ 個々のノードについて見ていきます。
| ノード | 要素 | 説明 |
|---|---|---|
| 開発端末 | Windows 10 | 開発端末のOS |
| Visual Studio 2022 | 統合開発環境 | |
| ComponentOne for WPF | WPFの統合UIコンポーネントパッケージ | |
| SPREAD for WPF | WPFのグリッド・スプレッドシートライブラリ | |
| Docker Desktop | 開発時に認証・販売・製造などのノードを利用する場合、Dockerを利用することとします。また購買ドメインのWeb APIやデータベースでもDockerを利用することになると思われるので、個人ごとにDocker Desktopのライセンスが必要でしょう | |
| Test Assistant Pro | WPFのUIテストを自動化する際のサポートツール。OSSだけでもテストはできますが、これを利用することで圧倒的に生産性が向上します。生成されるテストコードがきれいでリーダブル＆リライタブルなところが好み | |
| リソース管理 | GitHub（Enterprise） | ソースコードのリソース管理にはGitHubを利用します。GitHubの認証にはSSOを使うこととします。そのためEnterpriseのライセンスが必要となります。GitHubを自らホストするGitHub Enterpriseを利用するという意図ではありません。サーバー自体はGitHub管理のマネージドサービスを利用します |
| CI | GitHub Actions | Enterprise契約の費用範囲に収まるものと想定 |
| テストエージェントホスト | Windows 10 | WPFのUI自動テストを行うとした場合、テストランナーをユーザープロセスで動作させる必要があります。購買アプリが動作するクライアントと同じOSをいずれかに用意する必要があります |
| Docker Desktop | UIの自動テスト時に必要となる可能性があります。なしでテストすることも可能ですが、現時点で確定しきれないので載せておきます | |
| self-hosted runners | GitHub Actionsのエージェント。おもにWPFのビルド、テストに利用する | |
| .NET 6 | 購買アプリケーションのランタイム | |
| ComponentOne for WPF | CI時にビルドするため配置が必要。ライセンスはユーザーライセンスに含まれており、ライセンス範囲内（1名あたり最大3台まで）であれば個別購入は不要 | |
| SPREAD for WPF | 同上 | |
| クライアント | Windows 10 | 利用者のOS |
| .NET 6 | 購買アプリケーションのランタイム | |
| 購買アプリ | 開発対象のアプリケーション | |
| Web API | .NET 6 | 購買APIのランタイム。実行環境のOSなどについては本稿では限定しない |
| 購買API | 購買アプリからバックエンドを利用するためのWeb API | |
| データベース | SQL Server 2022 | 購買アプリケーションのデータの永続化先。購買APIを通して利用する |
こうして俯瞰してみると、Visual StudioのライセンスはGitHubのEnterpriseライセンスが含まれる「Visual Studio Subscription with GitHub Enterprise」が良いなと明確になるでしょう。Visual StudioとGitHubのライセンスを個別に用意してしまうようなことは、案外起こりがちです。
物理構成の決定
論理構成を検討したことで、おおよそ何が必要になるのか見えてきました。ただ論理構成だけだと隠れてしまっている要素があります。
- 1論理ノードは1物理ノードとなる訳ではない
- 1論理ノードは展開される物理ノードはすべて同じ種別のノードとも限らない
これらは物理構成まで検討することで明確になります。一度にまとめてやろうとすると大変で見落としやすいので、分けて考えると単純化できます。
物理構成を整理した結果が次の図です。
UMLの配置図に記載しています。各構成要素はつぎのとおりです。
| 要素 | 説明 |
|---|---|
| パッケージ | ネットワークのおおよその領域。 |
| ノード | 物理的なノード。GitHubなど購買ドメイン外のノードは1役割1ノードに単純化して記載しています。 |
| コンポーネント | 論理構成のノードを、物理構成ではコンポーネントとして記載しています。 |
各ノードの詳細は下記の通り。
| パッケージ | ノード | 数量 | 説明 |
|---|---|---|---|
| Internet | GitHub | 1 | リソース管理とCI環境を提供する |
| 自社 | 個人端末 | n | 開発用個人端末。プロジェクトメンバー数＝自社の個人端末数＋リモート環境の個人端末数 |
| テストエージェントホスト | n | CI時にWPFの自動テストを実施するテストエージェント。自動テストに時間がかかるため、複数台で負荷分散する | |
| リモート開発環境 | 個人端末 | n | 開発用個人端末 |
| 顧客オフィス | 顧客個人端末 | n | 購買WPFアプリケーションが動作するクライアント運用ノード |
| 顧客DC | ロードバランサー（既存） | 1 | Web APIのロードバランサー。顧客DC内にもともと存在するものを利用する |
| Web API | n | 購買WPF向けのWeb APIを提供する。ロードバランサーによりn台で負荷分散する | |
| データベース | 1 | 購買WPF向けのデータベース。顧客仮想環境上に構成するため、クラスター化せずシングル構成とし、障害時は新しいインスタンスを起動する | |
| 認証 | 1 | 統合認証サービスを提供する | |
| 販売 | 1 | 販売ドメインを構成する。製品情報と販売情報を購買ドメインに提供し、購買数を決定する | |
| 製造 | 1 | 製造ドメインを構成する。製造情報を購買ドメインに提供し、購買数を決定する |
数量がnとなっている箇所は、実際にはそのプロジェクトに応じた具体値を入れます。それほど複雑度の高くない構成ですが、テストエージェントホストについては注意が必要です。
WPFの自動テストは、ユーザーセッションで実施する必要があります。そのためログインしたままのデスクトップでself-hosted runnerを動かしておく必要があります。また並列実行もできません。なんらかのVMで実行してもよいですが、案外コストがかかります。古い開発機を再利用することを考慮してもよいでしょう。
またテストエージェントホストごとに、WPFのUIコンポーネントであるComponentOneやSPREADのライセンスが必要です。ライセンスは1ライセンスあたり3台利用できますが、注意は必要です。とくに初期が大規模開発で、アプリケーションの規模が大きく、継続開発や保守運用が小規模だった場合、ライセンス更新を絞る可能性があります。アプリケーションの規模が小さくなりますが、テストエージェントホストの数は減らせないので、テストエージェントホスト上のライセンスが不足しないように注意が必要です。
論理構成と物理構成を整理すると、アーキテクチャ的に必要となる予算額がおおよそ見えてくるはずです。
