#アーキテクチャ
22 件の記事
なぜWeb開発ではドメインが見えにくくなり、最終的にドメインが必要になるのか
マイクロサービスやモジュラモノリスの境界設計で立ち返るべき「ドメイン」とは何かを整理し、Web開発の現場でドメインが見えにくくなってきた構造的な理由と、その向き合い方を解説する。
Maybe Postgres Is Enough：別のDBを足す前にPostgresで足りるか考える
キャッシュや全文検索のために別のミドルウェアを足す前に、Postgresで足りないか確認したい。postgresisenough.devを参考に、用途ごとの代替機能を一覧で簡潔にまとめる。
GraphQLの採用判断とトレードオフ
GraphQL をいつ採用すべきかを、型システムや単一エンドポイント、オーバーフェッチ解消といった本質から整理します。向く場面と向かない場面、トレードオフ、N+1 などの運用、REST や gRPC との使い分けまで解説します。
gRPCの採用判断とトレードオフ
gRPC をいつ採用すべきかを、RPC・HTTP/2・Protocol Buffers の本質から整理します。向く場面と向かない場面、トレードオフ、運用の勘所、REST や GraphQL との使い分けまで解説します。
プラットフォームの成立条件
社内でプラットフォームを作るべきかどうかをどう判断するか。コア／支援／汎用サブドメインの区別、外部サービスとの比較、レバレッジ、体制などの観点から整理し、ドメイン分析でどこまで判定できるかを考える。
プロダクト開発とプラットフォーム開発は何が違うのか
「なぜ小さくリリースして検証しないのか」——プラットフォーム開発の意思決定に向き合うとき、この問いと頻繁に対峙する。判断基準・設計思想・投資観点の3つの観点から両者の違いを整理する。
アーキテクチャ戦略・戦術・設計の書き分け
アーキテクチャのドキュメントを書く際に迷いがちな「戦略・戦術・設計」の書き分けを整理した記事。三層構造として捉え、Why・What・How・When・Where・Whoという5W1Hのフレームワークを使って、それぞれに何を書くべきかを明確にする。
良いアーキテクチャ戦略・悪いアーキテクチャ戦略
アーキテクチャ戦略を立てても、形だけになったり実行に移されなかったりして機能しないことがあります。この記事では、書籍『良い戦略、悪い戦略』も参照しながら、課題分析・方針・施策という要素の観点から良い戦略と悪い戦略の違いを整理します。
なぜ・いつアーキテクチャ戦略を書くべきか
なぜ・いつアーキテクチャ戦略を書くべきかについて解説する記事です。「書く時間があるなら手を動かしたい」「書いても読まれない」といった声がある一方、戦略がないまま進めるとさまざまな問題が生じます。戦略を書く意義と、書くべきタイミングを整理します。
ADRを書くときに抑えておくべきポイント
ADR（アーキテクチャ決定記録）を書くときに押さえておきたいポイントを、経験をもとに4つに整理した記事。意思決定を一つに絞るアトミック性、トレードオフの記録、チームでの議論、テクニカルライティングの原則に焦点を当てる。
要件と制約の違い
ソフトウェア設計における「要件（Requirements）」と「制約（Constraints）」の違いについて、ISO 29148の定義をもとに整理した記事です。設計を考える際に混同しやすいこの2つの概念を明確に区別することで、アーキテクチャのトレードオフ判断に役立てることを目指します。
アーキテクチャアドバイスプロセス（AAP）とは何か？
アーキテクチャアドバイスプロセス（AAP：Architecture Advice Process）とは何かについて、調べたことをまとめた記事です。意思決定を中央集権的にせず、関係者からアドバイスを受けたうえで決定者が意思決定を行うこのプロセスの考え方や、ADRとの関係、実践的な進め方を解説します。
技術的な意思決定において制約やトレードオフを明示することの重要性
技術選定や設計判断を行う際に、制約やトレードオフを明示することの重要性を解説した記事です。意思決定は限られた条件下で複数の選択肢から選ぶ行為であるという前提に立ち、判断の背景を明文化することが将来の再評価や組織の成長につながる理由と、その記録の残し方を紹介します。
アーキテクチャ・アーキテクト・アーキテクティングについて
アーキテクチャ・アーキテクト・アーキテクティングの定義を解説。IEEE規格に基づくシステム構造、コンポーネント関係、設計判断、ステークホルダニーズ統合の本質を理解する実践的知見を紹介します。
設計の賞味期限を考える
システム設計に「正解」はなく、状況に応じた「最適な妥協」があるだけだという前提に立ち、「設計の賞味期限」という観点から設計の寿命をどう見積もるかを考えます。ビジネス・組織・プロダクト・技術の変化と制約、トレードオフを踏まえた意思決定のヒントを整理します。
アーキテクチャドキュメントを書くときに気をつけること
システム設計において重要な役割を果たすアーキテクチャドキュメントを書くときに、気をつけることをまとめた記事です。単なる設計情報の羅列ではなく、関係者に設計の妥当性を説明して合意を形成し、読者の理解と納得を導くための資料として、どう書くべきかを解説します。
アーキテクチャ戦略について考える
アーキテクチャ戦略について考えた記事。CTOやアーキテクトといった明確なポジションでなくても戦略の必要性を感じる場面を起点に、システムを構築・進化させるための方針として、ビジョンや原則、拡張性の計画といった観点を整理する。
信頼性のパターンについて
信頼性（Reliability）を高めるための設計パターンを、Azure・AWS・GCPが提唱するパターンに基づいてまとめた記事です。ユーザーが期待する機能を提供し続けるために、サーキットブレーカーや補正トランザクション、イベントソーシング、Pub/Subといったパターンを使って耐障害性・回復性を実現する方法を整理します。
C4モデルとは｜アーキテクチャを図解する4つの階層
ソフトウェアアーキテクチャを可視化するC4モデルを解説。システムコンテキスト・コンテナ・コンポーネント・コードの4階層の図でアーキテクチャを表現する方法を紹介します。
SaaSのアーキテクチャについて知るためのリスト
「SaaSなんもわからん！」から「SaaS完全に理解した！」に近づくために、参考になりそうな資料をまとめた記事です。AWSの『SaaSアーキテクチャの基礎』をはじめ、SaaSのアーキテクチャや設計を学ぶうえで役立つドキュメントやリンクを整理して紹介します。