アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

162

一方で以下のデメリットがあります。

●

サンプルであるゆえにリアリティが低く、実際のユースケースを実

装する段階になって共通機能の不備や不足が見つかるリスクがある

●

サンプル用のデータベース設計などの余計な作業が発生してしまう

リアルなユースケース

もう一つの方法は、リアルなユースケース、つまり実際にシステムの

利用者に対して提供されるユースケースを選定することです。

この場合、ランダムにユースケースを選ぶのではなく、アーキテク

チャ上重要なユースケースを選定します。アーキテクチャ上重要なユー

スケースとは、それを実行することでアーキテクチャの要所を検証可能

なものを指します。具体的には以下を満たす必要があります。

●

アプリケーション基盤に必要な共通機能を網羅できる

●

アプリケーションの各層、各コンポーネントタイプの処理が流れる

●

データベースや外部サービス連携など、主要な外界との接続を検証

できる

●

初めて利用するライブラリなど、技術リスクのある箇所を検証でき

る

一つのユースケースだけで上記すべてをカバーすることは難しいの

で、必要十分な数の複数のユースケースを選択することになるでしょ

う。業務上重要なユースケースとアーキテクチャ上重要なユースケース

とが概ね一致することも多いです。

第3章のケーススタディを例に考えてみましょう（図4.3.1）。「 経 費

精算を申請する」ユースケースを選ぶと、図中の太い矢印に沿って処理

が流れるため、経費精算サービス内の各層のコンポーネントの処理や

データベースアクセスを実装することになります。また、証憑管理サー ...