
164
複雑度や難易度の問題に関して言うと、あくまで主目的はアーキテク
チャの実装ですので、ユースケースのすべてのシナリオやバリエーショ
ンを実装する必要はありません。主成功シナリオと代表的な例外シナリ
オに絞れば問題ありませんし、業務ルールは仮実装としておいて構いま
せん。
筆者の意見としては、可能な限りリアルなユースケースを用いること
を推奨します。あるいはハイブリッド案として、初めはサンプルのユー
スケースを使って基本的な実装をしておき、次にリアルなユースケース
を用いて実装を洗練させるという戦略も考えられます。
ユースケースの実装
それでは、選定したユースケースを実装していく流れを見ていきま
しょう。
この段階では既にアプリケーションアーキテクチャは選定済みで、採
用するアーキテクチャスタイルは決まっている想定ですが、第3 章で述
べたように抽象度をコンポーネントレベルに下げて責務の割り当てや相
互作用を決めていく必要があります。
ケーススタディでは経費精算サービスはクリーンアーキテクチャを採
用することとしたので、クリーンアーキテクチャをベースに「経費精算
を申請する」ユースケースにおけるコンポーネントの配置や相互作用を
検討します(図4.3.2)。図はクリーンアーキテクチャの同心円の一部を
拡大したものです。各層に配置するコンポーネントやそれらの関係性を
描いています。吹き出しで付けたコメントは、アーキテクチャ上の考慮
が必要な箇所や、共通機能の候補についてのメモ書きです。なお、実装
に着手する前の予備設計という位置付けなので、実際には図をきれいに ...