やったこと

• Design It! 7章 パターンで土台を作る 読了

学んだこと

ポイント

• パターンとは
• パターンを用いるメリット
• 「アーキテクチャ上の不一致」とは

学び

• パターンとは、先人の知恵の集合体
• パターンを利用することで、以下のようなメリットがある
  • アーキテクチャの選択にかかる時間を大幅に短縮できる
  • パターンの名前で円滑なコミュニケーションをとることが出来る
• 「アーキテクチャ上の不一致」とは、達成したい品質特性と、選択したアーキテクチャが得意とする品質特性が一致しない現象
  • そもそもアーキテクチャの選択が不適切
  • アーキテクチャは適切だが、使用する技術がアーキテクチャに合っていない

所感

パターンを知らなければ、選択することもできない。
まずは、パターンを知るところから。

巨大な泥団子には悪いイメージしかなかったが、意図的に選択するユースケースをしった。
巨大な泥団子もアーキテクチャであり、アーキテクチャである以上トレードオフが存在する...ということだった。
（なお、基本的に良い事はない）

"問題重視"と"解決策重視"という二つ観点は考えたことが無く、興味深かった。

メモ

新しい問題に直面した場合、先人の知恵を借りると良い。
つまり、パターンとして整備されたアーキテクチャを選択する。
選択したアーキテクチャを、問題に合うようチューニングする。

この章で扱うこと

• 有名なアーキテクチャパターンの紹介
• アーキテクチャをチューニングする方法
  • 深く触れず、軽く説明する

アーキテクチャパターンとは

アーキテクチャパターンとは、過去にある問題を解決したことがある、再利用可能な解決策。

パターンを使用すると、以下のメリットがある。

• 適したパターンを選択できると、アーキテクチャの設計を大幅に短縮できる
• パターンの名前で円滑なコミュニケーションをとることが出来る

レイヤー

ある関心事１つを、１つのレイヤーとして実装する。
関心事別にレイヤーを分割し、複数人での共同作業を可能とする。

以下を満たすように実装する。

• レイヤー間は疎結合
• レイヤ内は高凝集
• 下位レイヤーは、上位レイヤーに依存しない
  • 言い換えると、下位レイヤーを取り換えても、上位レイヤーが動くよう実装する

ポートとアダプター

別名 ヘキサゴナルアーキテクチャ。

核となるビジネスロジックと、その他関心事を分離するパターン。
その他関心事と、取り換え可能なアダプターとして実装する。
アダプターは、ビルド、または実行時に取り換え可能。
これにより、柔軟な動作を可能とする。

パイプとフィルター

一つのデータ操作を、「フィルター」という単位で実装する。

• フィルターは、ある一つのデータ処理のみを担当し、処理結果を出力する

データをたくさんのフィルターに通して、目的の処理を実現する。

フィルターを並列に処理する場合は「パイプとフィルター」と呼ぶ。

フィルターを直列に処理する場合は「バッチシーケンシャル」と呼ぶ。

• 一フィルターの処理が重く、次のステージのために結果をファイル化する必要があるような、重たい処理を想定

サービス指向アーキテクチャ

特定の機能を１つ提供するコンポーネントを実装。
このコンポーネントを組み合わせて、任意のサービスを実現するアーキテクチャ。

サービス利用者は、背後にある実装の詳細を知らずに、目的を達成できる必要がある。

旧来は、メッセージバスおよびSOAP経由の通信に依存する形が主流だった。
現在では、HTTP などのメッセージプロトコルを使用して相互に通信する、マイクロサービスの使用を奨励している。

パブリッシュ・サブスクライブ

コンシューマー、プロデューサー（パブリッシャー）に分けて実装する。

コンシューマーは、事前に関心のあるイベントのみ購読（サブスクライブ）する。
プロデューサーは、自身が観察しているイベントを観測した場合、イベントを発行（パブリッシュ）する。
コンシューマーは、興味のあるプロデューサーのイベント発行を検知し、即座に目的の処理を実行できる。

共有データ

システム全体で共有するデータソースを作成する。
あらゆるコンポーネントがこのデータソースにアクセスして処理を実現する。

RDBとか、オブジェクトストレージとか。

多層

実行時の構造単位でレイヤーを分割する。
レイヤーパターンとは、分割する単位が異なる。

• レイヤーパターン : 設計時の要素単位でレイヤーを分割する
• 多層パターン : 実行時の要素単位でレイヤーを分割する

また、分割した層単位で、割り当てるサーバーやプラットフォームを選択できるイメージ。

コンピタンスセンター

専門家チームを雇い、彼らにパターンの定義、ベストプラクティスの確立、サポートツールの開発、教育などを担当してもらう。

システム開発ではなく、開発補助を目的とするパターン。

オープンソース型の貢献

チーム以外の第三者も開発に参加するパターン。

チームは、開発に加え、第三者の変更依頼をレビューし、メインのコードにマージする裁量を持つ。

• チームには、書き込み権限を与える
• 第三者には、変更依頼を提出する権限を与える
• チームは、第三者の開発を促進するため、以下を実施する
  • スタイルガイドの用意
  • テスト容易性を考慮した設計
  • 技術に制約を課してプラットフォームを構築

巨大な泥団子

特に定義された要素や関係はない。
開発プラクティスの未熟さ、アーキテクチャへの理解不足などに起因する、保守や拡張が困難な状態を指す。

設計への理解不足に起因するが、設計作業をスキップし、意図的に泥団子を選択することが出来る。
この場合、設計に割く時間を丸々カットできる、つまり開発スピードを一時的に促進できるメリットがある。

• 泥団子自体は保守困難なため、長期的な開発を視野に入れるなら、早い段階で泥団子を解体する必要がある

アーキテクチャ上の不一致を避ける

達成したい品質特性と、選択したアーキテクチャが得意とする品質特性が一致しない現象を、「アーキテクチャ上の不一致」という。
アーキテクチャ上の不一致は、以下の理由で起こり得る。

• そもそもアーキテクチャの選択が不適切
• アーキテクチャは適切だが、使用する技術がアーキテクチャに合っていない
  • Pub/Subパターンを選択し、データの受け渡しにRDBを選択する

アーキテクチャ上の不一致が発生した場合、フレームワークとの戦うことになる。
アーキテクチャ上の不一致を発生させないためにも、適切なアーキテクチャの選択に加えて、アーキテクチャの前提に一致する技術を選択する必要がある。

新しいパターンを発見する

新しいパターンを見つける、以下の2つの方法が知られている

• 経験した問題たちから、共通の問題を探してパターン化する "問題重視のアプローチ"
• 問題の解決策たちから、共通の解決策を探してパターン化する"解決策重視のアプローチ"

発見したパターンは、フィードバックを得るために発信しよう。