「アーキテクトの教科書」読書メモ

全てのビジネスがソフトウェアビジネスとなりつつある。

SoE領域：
顧客との繋がりを強化するITシステム
何が正解かわからないため、仮説検証が大事。

SoR領域：
企業活動に関わる情報を記録するためのITシステム
業務のやり方にパッケージを合わせる。

市場投入までのスピードが大事。
MVPをさっさとリリースして、顧客の反応を見ながら軌道修正するのが大事。

アンチパターン：巨大な泥団子

SOA

要望：顧客ニーズ
要求：要望を実現するためにシステムを使って達成すべきこと
要件：要求のうち、顧客と実現について合意し、開発の観点で具体化したもの
仕様：要件を検証可能なレベルまで詳細化したもの

SOLID原則

• 単一責任の原則
• オープン・クローズドの原則
• リスコフの置換原則
• インターフェース分離の原則
• 依存関係逆転の原則

CLEANコード

• Cohesive（凝集性）
• Loosely Coupled（疎結合）
• Encapsulated（カプセル化）
• Assertive（断定的）
• Nonredundant（非冗長）

ドメインロジック：
業務の知識やルールを表す中核ロジック

アプリケーションロジック：
業務処理の手順を表す処理フローロジック

GoFのデザインパターン

アーキテクチャとは、課題を解決しユーザーに価値提供をする目的を達成するために備えるべき特性を具現化するもの。

アーキテクチャドライバとは、検討するうえで重要な考慮事項のこと。
制約、品質特性、影響を与える機能要求、その他の影響を及ぼすもの。

制約はビジネス上の制約と技術的な制約に分かれる。

品質には外部品質と内部品質の2つあり、性能や使い勝手のようなユーザーから見える品質を内部品質、保守のしやすさといったユーザーから見えない部分を外部品質をという。

モノリシックアーキテクチャとは、全ての必要な機能を1つにまとめ、大きなアプリケーションとすること。
モノリスは一枚岩と言う意味を持つ。

分散アーキテクチャとは、機能を分割し、各々が独立してデプロイ可能なアプリケーションとして構築するアーキテクチャ。
個々のアプリケーションはサービスと呼ばれる。

モノリスはソースコードの管理が容易、トランザクションの整合性を保つのが容易、技術を統一しやすい。

モノリスのデメリットは、ビルドなどの時間がかかる、巨大な泥団子パターンに陥ることで保守の低下、単一データベースのボトルネック化、DLL地獄、新しい技術の採用の妨げなどが挙げられる。

分散アーキテクチャのメリットは、ビルド時間などの短縮、アジリティの向上、個々のスケーリング、サービスごとに個別に技術選定、サービス単位での再利用。

分散アーキテクチャのデメリットは、管理の複雑性、障害発生時の原因調査の困難さ、トランザクションの整合性の困難さ、サービス間通信が起因のレスポンス低下、データ共有問題、設計難易度の高さ。

モノリスで十分ならモノリシックアーキテクチャを選択するとよい。
例えば、小規模サービスとか。

ある程度の規模になれば、分散アーキテクチャに変更する。

サービスベースアーキテクチャ：複数のサービスが単一のデータベースを共有する。
トランザクションは単一サービス内で完結する。

マイクロサービスアーキテクチャ：各々のサービスが専用のデータベースを持つことで、サービス間のデータを完全に独立させる。
ほかのサービスとのやり取りが頻繁に発生するためにトランザクションがサービスをまたぐことがある。

APIゲートウェイにクライアントのリクエストを1点に引き受ける場合もある。

sagaパターン：
データ不整合を防ぐためにDBに登録するデータは仮状態とする。
エラーが発生した場合は仮状態のデータを取り消す。
エラーが発生しなかった場合はデータを確定する。

または、トランザクションを打ち消すトランザクションを指示する。
これを補償トランザクションと言い、結果整合性を確保するための調整を行う。
打ち消すということは、既に確定した状態であるため、仮データではない。

方法はあるが、サービス間をまたぐトランザクションは避けたほうが良い。

オーケストレーション：調整役を介してサービス間のやり取りを行う。
コレオグラフィ：各サービス間が自分たちでやり取りを行う。

基本的にはオーケストレーションが良い。

BFFとは、クライアントアプリケーションごとに専用のAPIゲートウェイを用意すること。

レイヤードアーキテクチャ：アプリケーションをいくつかのレイヤーに分け、各レイヤーの役割を明確化、役割に沿うようにコンポーネントを各レイヤーに配置。

例えば、プレゼンテーション層、ドメイン層、データアクセス層の三層に分けたものは三層レイヤードアーキテクチャと呼ばれる。

クリーンアーキテクチャは外側の層から内側の層に向かう依存関係のみが許可されている。
そのため、内側から外側への依存関係を発生させることはできない。

ビジネスルールが単純な場合は複雑性が増すだけで意味はない。

パイプラインアーキテクチャはパイプから受け取った入力値をフィルターが逐次的に処理し、その結果を後続に繋いでいくコンポーネント。

シェルなどが最たる例

マイクロカーネルアーキテクチャはコアシステムとプラグインから構成される。
コアシステムはシステムの核となる最小限の機能を実現するコンポーネント。

データベースにかかわる設計書はプロジェクトの規模によらず必ず作成したほうが良い。

セッションオブジェクトの中がごった煮状態でセッション情報が格納されることで、キーの重複やセッションオブジェクトの肥大化、複数タブを開いて利用することによるセッション情報の衝突などの問題がある。

そのため、セッションオブジェクトを論理的な区画に分けて管理するとよい。

git-flowとGitHub Flow

シフトレフト

処理フローロジックの正しさはユニットテストで検証するのではなく、より上位のテストに任せた方がよい。

中核ロジックにあたるコンポーネントに対して集中的にユニットテストを行う。

ロングランテストで見つかる障害の大多数がメモリリーク。