執筆動機

『ソフトウェアアーキテクトが知るべき97のこと』の 42.デザインパターンに習熟せよを理解するためのまとめです。

『ソフトウェアアーキテクトが知るべき97のこと』は、エンジニアに有名な書籍『プログラマが知るべき97のこと』のシリーズとも言える書籍（※両方ともWeb上から閲覧が可能）で、プログラマの方よりもより設計に特化した思想について書かれている書籍です。

97のことシリーズには97本の短い原稿がまとまって1冊の書籍となっており、さらっと読めるものもあれば、専門用語と専門知識を前提としていて長さの割に頭を使う必要のあるものもあったりと、さまざまです。

本記事では、『ソフトウェアアーキテクトが知るべき97のこと』の中の「長さの割に頭を使う必要のあるもの」に該当する項、「42.デザインパターンに習熟せよ」を理解するために中身をある程度かみ砕いてみたいと思います。

いろいろ書きましたが、要するに読みながら一体何を言っているんだという状態になったので、自分のためにまとめてみよう！という主旨です。

デザインパターンとは

デザインパターン

まず、デザインパターンとは。
Wikipediaによれば、要するに 「再利用性のある設計ノウハウ」 のことを指すらしい。

ソフトウェア開発におけるデザインパターンまたは設計パターン（英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。

🔗 Wikipedia

デザインパターンの有用性

デザインパターンを知っていることでより有用な設計が行えるようになる、ということは前提ですが、くわえて、デザインパターンを知っていることが パターンを使っているアーキテクトやデベロッパーと相互にコミュニケーションを円滑にするための手段 となります。

ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。そのための手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。

有能なソフトウェア・アーキテクトになるためには、基本的なアーキテクチャー/デザインパターンを理解し、それらがどのようなときに使われているか、どのようなときに適用すべきかを学び、パターンを使っているアーキテクトやデベロッパーとコミュニケーションを取ることができなければなりません。

🔗 42.デザインパターンに習熟せよ

本項でのデザインパターン4分類

4分類

個人的に読んでいてここから全く知らない世界線になったのですが、本項の内容によれば、デザインパターンは基本的に以下の4種類に分類できるそうです。

1. エンタープライズ・アーキテクチャパターン
2. アプリケーション・アーキテクチャパターン
3. インテグレーションパターン
4. デザインパターン

※GoFデザインパターンなどは一旦横においておいて、この項の内容を理解することに努めます

これらのカテゴリは、一般にアーキテクチャ全体の中に占めるスコープの大きさによって分類されているそうです。

以下、それぞれのパターンについて「デザインパターンに習熟せよ」に書いてある説明をまとめつつ、理解しやすい情報を補足して説明していきます。

1. エンタープライズ・アーキテクチャパターン

本に書かれていること

高水準のアーキテクチャーを対象とする
アーキテクチャーの枠組みを定義する
具体例
- イベント駆動型アーキテクチャー(EDA)
- サービス指向アーキテクチャー(SOA)
- リソース指向アーキテクチャー(ROA)
- パイプラインアーキテクチャー

🔗 42.デザインパターンに習熟せよ

調べたこと

本に書かれていることに加えて、大規模で複雑なシステムを構築する時に役立つ設計パターンとのこと。

エンタープライズアプリケーションアーキテクチャパターンとは、大規模で複雑な企業向けアプリケーション（エンタープライズアプリケーション）を設計・構築する際に役立つ、実績のある設計パターンの集まりです。
これらのパターンは、開発者が直面する共通の課題に対する解決策を提供し、システムの保守性、拡張性、パフォーマンスなどを向上させるために役立ちます。

🔗エンタープライズアプリケーションアーキテクチャパターン | 今更聞けないIT用語集

例として挙げられていたのが下記。

レイヤードアーキテクチャ

ドメイン駆動設計（DDD）

マイクロサービスアーキテクチャ

イベント駆動アーキテクチャ

🔗エンタープライズアプリケーションアーキテクチャパターン | 今更聞けないIT用語集

解釈

つまり、まず何らかの大規模な業務なり課題なりがあることを前提としている。

＝対象スコープ：企業全体や、大規模なシステム全体

たとえば、「パーティーをしましょう🥳」となった時に、まずパーティー全体の構成を考える、という段階に使える設計パターン。

大体パーティーってみんなでご飯を食べるよね、とか、ビンゴをすることもあるよね、とか、そういう大枠をどのように展開するのが定石かといった俯瞰的な視点を考える時に使うようなもののようです。

2. アプリケーション・アーキテクチャパターン

本に書かれていること

より大きなエンタープライズ・アーキテクチャーの中で、アプリケーションやサブシステムをどのように設計すべきかを規定する
具体例
- J2EEデザインパターン
  - たとえばセッションファサード、トランスファーオプジ、エクトなど
- アプリケーションアーキテクチャーパターン
  - マーチン・ファウラーの『エンタープライズアプリケーションアーキテクチャーパターン』(淘泳社)で取り上げられているもの

🔗 42.デザインパターンに習熟せよ

調べたこと

ソフトウェアのさまざまなシステムや要素の設計構造を、再利用できるようにするための設計パターン とのこと。

"The architectural pattern captures the design structures of various systems and elements of software so that they can be reused. During the process of writing software code, developers encounter similar problems multiple times within a project, within the company, and within their careers. One way to address this is to create design patterns that give engineers a reusable way to solve these problems, allowing software engineers to achieve the same output structurally for a given project."

🔗 Red Hat Blog

アーキテクチャー・パターンは、ソフトウェアのさまざまなシステムや要素の設計構造を捉え、再利用できるようにするものである。(中略)
ソフトウェアエンジニアが与えられたプロジェクトで構造的に同じアウトプットを達成できるようにすることである。
(Translated by Deepl)

Javaに明るくないので、J2EEについても調べました。
Javaで作られるシステムを構築するためのアーキテクチャパターン、とのこと。

J2EEとは、独立した製品ではなく、米国Sun Microsystems,Inc.が提唱したJavaによる分散アプリケーション向けのコンポーネントアーキテクチャおよび規約であり、Javaコンポーネント開発の標準仕様を指します。
J2EEは、多階層サービスの開発に伴うコストと複雑性を低減し、企業間競争への対応に伴って迅速に配備でき、かつ容易に拡張できるサービスを実現します。

🔗 Interstage Application Server J2EE ユーザーズガイド

解釈

＝対象スコープ
：エンタープライズ・アーキテクチャの中のアプリケーションやサブシステム

エンタープライズ・アーキテクチャパターンが全体の設計に該当するのに対し、アプリケーション・アーキテクチャパターンはもう一段スコープが狭く、具体性がある。
具体的に言うと、該当システムの範囲の中のアーキテクチャを考えるための設計パターン。

「1.エンタープライズ・アーキテクチャパターン」で考えた一要素の、たとえば「ビンゴ大会🎯」というに対して、それをどのように展開していくのがよいかな、といったようなある程度具体性のある場面で設計を考える時に使う考え方のようです。

3. インテグレーションパターン

本に書かれていること

コンポーネント、アプリケーション、サブシステム間での情報や機能の共有に関連するコンセプトを設計したり、話題にしたりするときに重要なパターン
具体例
- ファイル共有
- リモートプロシージャコール(RPC)
- さまざまなメッセージングパターン

🔗 42.デザインパターンに習熟せよ

調べたこと

インテグレーションパターンは字面で「統合(integration)」を表している通り、何か複数のコンポーネントやサブシステムといったシステム内の機能を繋ぐ設計パターン。
何を「統合」するかというと、具体的には「通信」と「データ交換」を統合する。

The term “application integration patterns” refers to the various approaches and methodologies used to enable seamless communication and data exchange between different software applications within an organization’s IT ecosystem.

🔗 Application Integration Patterns to Empower Your Organization

「アプリケーション統合パターン」という用語は、組織のITエコシステム内で異なるソフトウェアアプリケーション間のシームレスな通信とデータ交換を可能にするために使用される様々なアプローチと方法論を指す。
(Translated by Deepl)

解釈

＝対象スコープ
：アプリケーションの中のコンポーネントやサブシステム同士の機能の連携

インテグレーションパターンは、アプリケーション・アーキテクチャによって考えられた個々の機能の設計とは別に、各機能ごとがどのように通信やデータを連携させるか、といった点に着目した設計パターン。

インテグレーションパターンを考える上で抑えるべきなのは、おそらく「連携」という観点。他の設計パターンと比較して、より扱う情報のレイヤーが低いというか（DBとか、ネットワークとか）、概念よりも実在に近い感じがする（※個人の感想です）

▶ これに関して、インテグレーションパターンはアーキテクチャパターンに該当するのか調べてみたところ「広義のアーキテクチャパターンではある」というような着地点だった？

システム全体の構造そのものというよりはデータの連携という観点が強いため、アーキテクチャパターンに含まれることがあれば含まれないこともあるらしい。

これは例えるならば、エンタープライズ・アーキテクチャパターンで考えたパーティーの計画の、計画ごとの各実行係がどう連携するのがいいかね？というような話に該当するように思います。具体的にいうと、ビンゴ担当係とディナー用意係はいつ落ち合う？何を伝える？買い出し係の人はどのタイミングでどの係の人から何を受け取るのがいいだろう… といったような想像。

4. デザインパターン

本に書かれていること

アーキテクチャーに含まれる個々のコンポーネントをどのような構造で作り、どのようにふるまわせるかを扱う

🔗 42.デザインパターンに習熟せよ

調べたこと

いわゆるオブジェクト指向を中心とした時に使用される設計パターン。
GoF関連の書籍は未読ですが、有名ですよね。

ソフトウェア開発におけるデザインパターンまたは設計パターン（英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。

🔗 Wikipedia -デザインパターン (ソフトウェア)

GoF（Gang of Four：ソフトウェア開発におけるデザインパターンの概念を普及させた4人の著者を指す通称）によって提唱された23のデザインパターンは、オブジェクト指向設計において重要な役割を果たしています。
GoFは1994年に『Design Patterns: Elements of Reusable Object-Oriented Software』という書籍を発表し、この書籍がオブジェクト指向プログラミングにおけるデザインパターンの基礎を築きました。

これらのパターンは、オブジェクト指向設計をより効果的に行うための「ベストプラクティス」として広く認識されており、ソフトウェアの保守性、拡張性、再利用性を高める重要な指針となっています。

🔗 GoFの23のデザインパターンを解説

書籍も未読で概念は詳細に調べられていませんが、調べてみた概要としては、クラスのインスタンスの扱いであったりとか、インスタンスの生成タイミングであったりとか、オブジェクトの継承に関する設計パターンであったりとか、所謂実際に手を動かしてプログラミングをする時に考える思想的な側面が強い設計パターンだと思います。

解釈

＝対象スコープ
：アプリケーションの中のコンポーネントやサブシステムの中の詳細な機能のつくり

デザインパターンは、実際に実装する時にどのようにメソッドやクラス構成を立てるのがよいか、という、プログラミング的思考が強い設計パターン。

例えるまでもなく最もエンジニアにとって親しみやすい領域ではあると思いますが、ここまでの流れを踏襲して例えるならば、パーティーのそれぞれの係の人は、係の中でどう役割分担するのがいいだろうか？といったところでしょうか。分担と動きを考えるのは大事です。

その他、「42.デザインパターンに習熟せよ」より

GoFの『オブジェクト指向における再利用のためのデザインパターン』に書かれている基本デザインパターンは、ソフトウェアアーキテクトがかならず持っていなければならない知識
- アーキテクトがデベロッパーとの問でコミュニケーションを取るための基本語彙
さまざまなアンチパターンについても学んでおくことが大切
- アンチパターン＝効率の悪い結果をもたらすのに繰り返されているプロセス
ソフトウェア・アーキテクトは、簡明かつ効率的にコミュニケーションを取れなければならない
- パターンを学び、理解して、「有言実行」できるようになるかどうかが、私たちソフトウェア・アーキテクトの課題

まとめ

調べたものを、まとめます。

アーキテクチャパターンとデザインパターンの違い

アーキテクチャパターン
- アプリケーションの個々のコンポーネントやサブシステムを包含して設計するためのパターン
デザインパターン
- アプリケーションのコンポーネントやサブシステム内の具体的な実装に関わる設計パターン
  - 主にオブジェクト指向で用いられる

アーキテクチャパターン/デザインパターンのそれぞれのスコープ

アーキテクチャパターン
- エンタープライズ・アーキテクチャパターン
  - 対象スコープ：企業全体や、大規模なシステム全体
- アプリケーション・アーキテクチャパターン
  - 対象スコープ：エンタープライズ・アーキテクチャの中のアプリケーションやサブシステム
インテグレーションパターン
- 対象スコープ：アプリケーションの中のコンポーネントやサブシステム同士の機能の連携
デザインパターン
- 対象スコープ：アプリケーションの中のコンポーネントやサブシステムの中の詳細な機能のつくり

今回調べたことによって、アーキテクチャパターンやデザインパターンの関係性がすっきりとしました。
個々の詳細についてはそれぞれ書籍を読むなりインプットが必要ですが、概要理解の助けになれば幸いです（何か間違いがあればコメントください）

やる気があったらやる今後の宿題

細々、やろうと思えばどこまでもやれますが、一旦わかりやすいNextStepをメモ。

デザインパターンのアンチパターンについて学ぶ
GoFの『オブジェクト指向における再利用のためのデザインパターン』を読む