kakudooo docs
アーキテクチャリングとデザイン(設計)の違い
ソフトウェアアーキテクチャの基礎を読んでいたところ、2章でアーキテクチャリングとデザイン(設計)の違いについて説明されている箇所があった。 「どこまでがアーキテクチャリングで、どこからが設計なのか。」「アーキテクトと開発者にどのような責務の違いがあるのか」について自分の理解も曖昧だったので、本の内容をベースに整理しておこうと思う。
アーキテクチャリング
以下の3つについての、成果物をそれぞれ作成すること
- アーキテクチャ特性
- アーキテクチャスタイル
- コンポーネント構造
について、アーキテクトが責任を持つもの
アーキテクチャ特性
ビジネス要件を分析してilityを抽出・定義する
アーキテクチャスタイル
定義したアーキテクチャ特性に対して、問題領域に適したアーキテクチャパターンやスタイルを選択する
コンポーネント構造
選択したパターンやスタイルから、コンポーネント（システムの構成要素）を作成する コンポーネントはアーキテクチャリングとデザイン(設計)の接続部分であり繋目である。 コンポーネントの作成はアーキテクトと開発者が協業する箇所である。
コンポーネントとは？
コンポーネントは一般に、アーキテクトが直接関わるソフトウェアシステムの構成要素のうち、 最も小さい要素であり、モジュールが物理的にパッケージ化されたもの。 Javaのjarファイル、.NETのdll、Rubyのgemなどをはじめ、ほとんどの言語でモジュール(関連するコードをまとめたもの)を物理的にパッケージ化する仕組みがサポートされている。
以下はコンポーネントの種類例
- サブシステムやレイヤー
- イベントプロセッサー向けのデプロイ可能ユニット
- 分散サービス(マイクロサービス)
コンポーネントの概念を用いることは必須ではないが、使うとアーキテクチャをシンプルに捉えることができるようになる。 アーキテクトはコンポーネントの中でも、最上位のコンポーネント分割に責任があるので、考える上で重要な概念となる。
コンポーネントは、階層化により入れ子構造になるものである。もっとも単純なコンポーネントは、関連コードをクラスや関数よりも高度なモジュールによってラップしたもの(ライブラリ)であり、サブシステムやレイヤー、イベントプロセッサー向けのデプロイ可能ユニット、サービスなどもコンポーネントとして表現する。 コンポーネントの概念を取り入れることで、前述した階層構造を基本としたアーキテクチャスタイルやパターンの組み合わせによる構成が可能になる
アーキテクチャリングの範囲
- アーキテクチャを構成するコンポーネントの定義、改良、管理、統制。
- ソフトウェアの初期設計。
コンポーネントを構成するクラスや関数の設計は、テックリードや開発者が担当する。
コンポーネントによるアーキテクチャの分割
コンポーネントを活用することでアーキテクチャの分割を行うことができる。 とりわけ、重要なのが最上位分割であり、基本とするアーキテクチャスタイルとコードの分割方法を定義することになる。
例えば、以下の図は、レイヤードアーキテクチャとモジュラーモノリスに関してのアーキテクチャスタイルを表すものである。
- レイヤードアーキテクチャを最上位のアーキテクチャスタイルとして、内包するコンポーネントをモジュラーモノリスにする
- モジュラーモノリスを最上位のアーキテクチャスタイルとして、内包するコンポーネントをレイヤードアーキテクチャにする
のように最上位のアーキテクチャはコンポーネントの階層を持つものである。
最上位分割の種類
技術による最上位分割
技術による分割では、システムの機能を、プレゼンテーション、ビジネスルー ル、サービス、永続化といった技術能力ごとに分割している。 レイヤードアーキテクチャの普及は、企業の部隊編成方法に興味深い副次的効果をもたらしてい る。レイヤードアーキテクチャを使用する場合に、バックエンドの開発者、DBA、プレゼンテー ションチームを、それぞれ別の部隊にするのは、わからなくはない理屈だ。コンウェイの法則に従 うなら、それは組織にとって意味を持つからだ。
ドメインによる最上位分割
このアーキ テクチャスタイルは、Eric Evans の『エリック・エヴァンスのドメイン駆動設計』(翔泳社)に触 発されている。ドメイン駆動設計(Domain-Driven Design:DDD)は、複雑なソフトウェアシス テムを分解するためのモデリング手法だ。DDD では、アーキテクトは互いに独立したドメインや ワークフローを見極める。マイクロサービスアーキテクチャ(「17 章 マイクロサービスアーキテ クチャ」参照)も、この哲学に基づくアーキテクチャスタイルだ。モジュラーモノリスでは、アー キテクトは技術能力ではなく、ドメインやワークフローを中心にアーキテクチャを分割する。コン ポーネントは互いに入れ子構造になっていることが多いため、図 8 - 4 のドメインによる分割例の各 コンポーネント(たとえば、CatalogCheckout)は、永続化ライブラリを使用したり、ビジネス ルールのために個別のレイヤーを持っているかもしれない。しかし、最上位分割は、あくまでドメ インを中心に行われる。
コンウェイの法則
組織構造はアーキテクチャを決めるというもの、アーキテクチャの変更を推進する場合は組織構造と両輪で推進する必要がある
コンポーネントと開発者の役割
“開発者は通常、アーキテクトと共同で設計したコンポーネントを、クラスや関数、サブコンポーネントなどに細分化する。一般的に、クラスや関数の設計は、アーキテクト、テックリード、開発者の共同責任で行われるが、その大部分は開発者の役割となる。 開発者は、アーキテクトが設計したコンポーネントを完璧なものと捉えてはいけない。すべてのソフトウェア設計は、イテレーションによってヒントを得る。むしろ、最初の設計は1回目の下書きとして扱うべきだ。実装することで、より多くの詳細や改良点が明らかになっていく。”
コンポーネントの設計手順
コンポーネントの抽出
コンポーネントの識別サイクル
コンポーネントの設計
コンポーネントを設計するための「正しい」方法は存在せず、様々な方法が存在する中でトレードオフがある。
コンポーネントの設計にあたっては、以下
- Entity Trapに注意する
- アクター/アクションアプローチ
- イベントストリーミング
- ワークフローアプローチ
あたりが避けるべき罠と、一般的な手法になる。
ここまでのまとめ
- ビジネス要求や組織状況に応じてパターンやスタイルを選択し、最上位のアーキテクチャをまず決める
- コンポーネントの概念を使い、最上位アーキテクチャとそれが内包するアーキテクチャを順番に決め、システムの構成要素を作成していく過程がアーキテクチャリングである。
- アーキテクチャリングにおいて、コンポーネントを構成するクラスや関数の設計までは極力踏み込まない
- デザインパターンの抽出や適用などはアーキテクチャと密接に関係することが多いため、アーキテクトも関与する領域になる
- 以下はコンポーネントの構成についてのイメージ
設計(デザイン)
アーキテクチャリングによって、作成したコンポーネントを特定の要件に基づいて具体化する作業であり、クラスや関数の設計のことを主に指す。 いわゆるモジュール設計のこと。 使用する言語やフレームワークに依存することから、使用する技術への深みが必要となる。 テックリードや開発者が責任を持つ
- クラス・関数設計
- UI
- ソースコード(実装)
などが成果物となる。
実際のソフトウェアを例に
Puma
アーキテクチャ
https://github.com/puma/puma/blob/master/docs/architecture.md
設計
https://github.com/puma/puma/tree/master
Moya
アーキテクチャ
https://github.com/Moya/Moya
設計
https://github.com/Moya/Moya
システムデザイン(設計)という用語について
- システムデザイン(設計)
- アーキテキチャリングやデザイン(設計)のプロセスを包含する範囲の広い概念
- 例えば、システムデザイン面接と言うと、アーキテキチャや設計両方に関して問うものを指す
- 設計は、アーキテキチャ設計とシステム設計の両方の意味を含む広言葉である