アーキテクチャ設計のプロセス
前回の内容はこちら
下記画像の通り３ステップから設計プロセスは構成されています。
・把握
・整理
・組み立て
今回はこれをそれぞれ解説して行きます。
アーキテクチャ設計の3つのプロセス
把握(Disclose)
プロジェクトが進むにつれて多くのコンセプト詳細が判明することもありますが、初期段階で重要なコンセプトを見落とすと複雑なリファクタリングが必要になる可能性があるので可能な限り多くのコンセプトを最初に把握することが重要です。
下記のように様々な項目について把握する必要があります。
- ビジネスコンセプト、連携ニーズ、非機能要件を把握する
- ユーザーストーリー、ペルソナ、ロールの種類、ユーザーが実行できる様々なアクションを把握する
- 既存のドキュメントを分析したり、ビジネス部門のステークホルダーと会話する
- 情報アーキテクチャに関して把握する
- ユーザーと話し合ったり、拡張またはリプレース予定の既存システムを分析する
- 連携するテクノロジーについて把握する
- 外部のソースシステムから利用する情報を把握する、また必要な連携必要な連携を把握する（APIのタイプ、通信プロトコル、I/Oストラクチャ、メッセージヘッダー）
- ユーザーエクスペリエンスについても把握する
- アクセシビリティは必須か、どのようなチャネルを計画しているか、モバイル専用アプリですか、Webアプリも必要か
整理(Organize)
把握の次段階とはなっているものの整理を進める中で新たに把握することもあるので結局把握と整理を並行して進めることになるため多少のイテレーションが必要になります。
また把握および整理のステップではモジュールでもアプリの成果物でもなく、あくまでコンセプトについて話し合いを進めるステップです
下記のルールに基づいて整理を実行する
- インターフェース関連のコンセプトやプロセスはエンドユーザーレイヤーに配置する
- コアビジネスコンセプトはコアレイヤーに配置する
- 連携ニーズと非機能要件は基盤レイヤーに配置する
組み立て(Assemble)
把握、整理で整えたコンセプトを組み立ててモジュールにして行きます。
下記の通りいくつかのルールがあります
- 概念的に関連するコンセプトを結合する
例）顧客と請求の2つのコンセプトが関連している場合、結合して同じモジュールにする - ライフサイクルが異なるコンセプトの場合は結合しない
例）契約と顧客という顧客という2つのコンセプトは関連しているものの契約していない顧客もいる場合はライフサイクルが異なるので結合するべきではない。 - 連携ロジックから再利用可能なロジックを分離すること
連携ロジックは基盤レイヤーに配置、再利用可能なロジックはコアレイヤーに配置する
→外部システムが変更され連携ロジックが変わっても再利用可能はロジックは保護される - なるべく既知の設計パターンを使用する
その他
プロセスが完了すると対応するレイヤーの各モジュールを示したアーキテクチャー設計図が完成。これに依存関係を追加することでアプリケーションの全体像を掴めるようになる。
プロジェクトの間ずっと把握、整理、組み立てのステップを繰り返すようにする。
次回
自分用のメモ書きを備忘録として残しているので口調がバラバラですみません…
余力があればそのうち直します、そのうち…
次回はモジュールの命名規則について記載していこうと思います。
コメント