【感想】『Design It! プログラマーのためのアーキテクティング入門』：モダンなアーキテクトへの地図とコンパス

　本の感想記事です。なかなか電子版が出ないので以前にAWS認定試験に受かった帰りに自分へのお土産用に物理本を買って積本に貯まっていたのですが、テレワーク中なのでじっくり読むことができました。
　原題は『Design It! From Programmer to Software Architect』。日本語版の副題の通り、プログラマーとしての活動からさらに上位に進みたい人や既にアーキテクトとして活動している人向けに、現代的なアーキテクティングの本質や手法、ソフトウェア・アーキテクトとしてのありかたを網羅した本となっています。原著は2017年刊行、日本語版は2019年11月。
　エンジニアがみんな大好き(あるいは眠くなる)オライリー本で380ページ弱ありますが本の物理サイズも小さく、内容も章と節で短い単位でまとまっているので割とすんなり読めます。アーキテクティングの見地からの用語は時々出てきますが、特定の技術の中に属する専門用語はそれほど出てこないのでそのへんも大丈夫です。
作者さん以外にも、各章には様々な立場で活動中の世界のアーキテクトの方々のコラムが出てきたりします。

　著者はIBM Watsonの開発にも携わりアジャイル関連のコミュニティでも活動しているMichael Keeling氏。序文でも様々人が本書を称賛しています。日本語版翻訳は様々な書籍の翻訳や日本Rubyの会で知られる島田浩二さん。またアジャイル関連の活動や本で知られる平鍋 健児さんが序文を飾っています。

Design It! ―プログラマーのためのアーキテクティング入門

www.oreilly.co.jp

　以下、各章ごとに概要や感想などを。

Ⅰ部 ソフトウェアアーキテクチャ入門

1章 ソフトウェアアーキテクトになる

　最初は基本。エンジニアリング観点からの問題定義や全体に目を向ける、品質特性の中でトレードオフを決める……などアーキテクトのやることを概観。よく聞く「技術的負債」のワードもアーキテクトの仕事のひとつとして出てきます。
　そしてアーキテクチャとは様々な性質を促進するためソフトウェアをどう構成していくか……なのだという定義でアーキテクチャの本質の話。本の引用でマーチン・ファウラー氏の名前が出てくるのですが、他にも文中のあちこちでソフトウェア開発の書籍の名や人の名、有名な言葉や一節や法則やキーワードがけっこう出てきます。
日本語訳が出ているものもあり、やっぱり評価の高い本に書いてあることやソフトウェア開発の世界の真理はみなどこかで繋がっているのだなと思います。

　実物の例も必要……ということで本書では全体を通して、実際にあったプロジェクトに基づいた架空の「Lionheart」プロジェクトでの実践の例が各章に載っています。
　先進的な自社サービスかと思いきや、スプリングフィールド市の行政管理予算局がやっている物品購入の契約周りの作業を効率化したいという、なかなかお堅い公共事業系のおしごと。けっこうな金額の大きい案件のようです。ステークスホルダーの代表は市長のジーン＝クロード・ヴァン・ダム氏となっています。

ライオンハート [DVD]

Lionheart - Trailer

　うーんマンダム。じゃなかったヴァン・ダム。ワイたちの木曜洋画劇場をスーパー・ヴァンダミング・アクションで飾ってきたヴァンダム兄貴をもじっています。最近はエクスペンダブルズ軍団に加わったりしてますが1990年の映画だからまだ30ぐらい、実写版『ストリートファイター』で爽やかにガイル大佐を演じてた頃よりも、もっと前の初期の作品ですね。

2章 デザイン思考の基礎

　タイトルにもあり本書に度々出てくる「デザイン」の言葉はWebデザインなどのUIやアート寄りのデザインでなく、アーキテクチャ的な設計の方のデザインです。デザイン思考の基礎として人間性、曖昧性、再デザイン、触感性(タンジブル)の４原則を解説しています。
　この「タンジブル(Tangible)」がちょっと日本語としてはなじみが薄いのですが、触って確かめられる、つまり構成図に書いたりなぜそうしたか記録を残したり喩え話で説明したり、抽象的になりがちなアーキテクチャの話を後からでも人に分かるようにしておく、という話でしょうか。
　そして理解、探求、作成、評価の４ステップを任意の順で繰り返していくのがデザインのマインドセットだと論じています。 　

第Ⅱ部 アーキテクチャ設計の基礎

3章 デザイン戦略を立てる

　事前に計画を立て、限られた時間の中でよりよい設計を探求したりリスクを減らしたりしていく話。差はあるものの、だいたいプロジェクト全体の中で20%前後をアーキテクチャ設計に費やすと良いと本書では述べています。
　工程の最初の方でまずいことをすると後の方で取り戻すのにより多くの時間がかかり大きな損失になる……というのはウォーターフォール的な開発でもエンプラ寄りの世界のマネジメントの話でもよく言われることですが、このへんはモダンなアーキテクティングでも同じですね。

4章 ステークホルダーに共感する

　技術から離れて一気にお堅い世界に突入しますが、お客さんを始めステークスホルダーをマップを作って整理したり、ちゃんと話を聞いて会話してビジネス目標を理解して、一緒にやっていくといいよという話。
　日本だとお堅いプロジェクトマネジメントの本などにもよく出てくる話ですが、章として用意してあるあたり、この辺が未経験だったり弱かったりする技術寄りのエンジニアはアメリカでも多いのかなと思います。

5章 アーキテクチャ上重要な要求を掘り下げる

　本書を通してよく登場する独自用語、「アーキテクチャ上重要な要求」(ASR: Architecturally Significant Requirement) の章。制約や品質特性や機能要求などをまとめ、優先度をつけて整理してアーキテクチャを決めていく話。よく聞く「コンウェイの法則」も本章で出てきて、最高のソフトウェアを設計したいなら組織も影響するからチームを再編成することも必要になる……という文脈で語られています。
　欄外のコラムで語られているのが「積極的傾聴者になることを学ぶ」というお題で、人の話をよく聞くことが大事で参考文献にカーネギーの『人を動かす』が出てきたりします。やっぱりこのへんの領域になるとコードや技術と向き合うだけでなく、人と上手くやっていくことがスキルとして必須になってくるのだなと思います。

人を動かす 文庫版

6章 アーキテクチャを選ぶ（君がアーキテクチャに選ばれる前に）

　刺激的なタイトルですが、技術トレンドに乗るだけでなくプロジェクトの制約や品質特性を考え、図や表に整理してアーキテクチャを選定していこうという話。
　スムージーを作るためのブレンダーの例でギャグをかました後、例が具体的になってWebアプリケーションも出てきます。７章で出てくる多層パターンやサービス指向アーキテクチャから選んでいく話、Web画面のUIから始まって後ろにロジックやクローラーがあるコンポーネント図……などなどが登場、実際に開発に携わっているエンジニアにもイメージしやすい話になってきます。

　章末実例のLionheartプロジェクトでも「意思決定マトリクス」でどのアーキテクチャパターンを選ぶか考えていくのですが、ここでそれぞれの性質を『促進する』～『中立』～『阻害する』の5段階でしるしをつけて考えていっています。
この表で数字を使うのは魅力的だが、してはいけないと論じているあたりは作者さんの豊富な実体験が元になっているのかなと思います。こういうアーキテクチャ選定の段階では、詳細に踏み込まず抽象度を高く保ったまま会話・議論していった方がよいのでしょうね。
　あと細かいところではこの意思決定マトリクスの例、「パフォーマンス」の性質について伝統的な３層アーキテクチャだと中立の『○』、サービス指向アーキテクチャだと促進の『＋』になっています。SOAにするとそんな速くなるんだっけ？とちょっと思いました。(Web画面を作って返すのでなく単機能のAPIで結果を返すだけだから速いとかのイメージでしょうか？)

　そしてソフトウェアの１つだけ不変のものとして「変化」が上げられています。本書はどこにもアジャイルという言葉が出てこないのですが、変化に対応しうる設計というのは現代的なアーキテクティングでより重要なのだなと思います。

7章 パターンで土台を作る

　代表的なアーキテクチャパターンを上げている章。このへんはアーキテクト職でなくとも馴染みのある方は多いのではないでしょうか。
　時々混乱されることのあるGoFを始めとするデザインパターンとアーキテクチャパターンの違いについても本書はコラムで解説しており、「両者は解決しようとしている問題の種類が違う」、そして厳密な線引きがないケースもあるという風に説明しています。解説されているパターンは以下。

• 7.2　レイヤー（Layers）
• 7.3　ポートとアダプター（Ports and Adapters）
• 7.4　パイプとフィルター（Pipe and Filter）
• 7.5　サービス指向アーキテクチャ（Service-Oriented Architecture）
• 7.6　パブリッシュ・サブスクライブ（Publish-Subscribe）
• 7.7　共有データ（Shared-Data）
• 7.8　多層（Multi-Tier）
• 7.9　コンピタンスセンター（Center of Competence）
• 7.10　オープンソース型の貢献（Open Source Contribution）
• 7.11　巨大な泥団子（Big Ball of Mud）

　「レイヤー」パターンはもうしょっちゅう使いますね。「サービス指向アーキテクチャ」(SOA)の言葉は日本でも最近あまり使わない気がするしAWS認定の資格の略称と被ったりしてますが、本書ではパターンとしてはSOAがあり、マイクロサービスアーキテクチャーはこの中に含まれるような形で扱っています。(このへんは海外でも曖昧なのかもしれません。)
　「パブリッシュ・サブスクライブ」はクラウド上だとAWSでSQSにメッセージを投げておいて後から非同期で順次処理していくようなやつですね。「共有データ」は、フロントエンドの技術で言うとVue.js+VuexやReact+Reduxでデータの置き場所をひとつにまとめるやり方も含まれるかもしれません。
　「巨大な泥団子」パターンは時々文献やスライドなどで目にするキーワードだったのですが、なんのことはない、設計や拡張性や再利用性をあまり考えず開発速度優先で出来上がっちゃったイケてない大きなかたまり的なブツのことでした。

8章 意味のあるモデルで複雑さを扱う

　難しい話ですが物事をモデル化して名前を付けて概念化し、アーキテクチャに活用していく話。プログラミングで常に重要かつみな悩む「よい名前付け」についても扱っており、他の本からの引用で名付けにステージ１～ステージ７まであることを解説しています。
　「パターンを分かりやすくするためにコードを整理する」の節でJavaアプリケーションを例にとり、クラスが属するレイヤーを論理的に構成するパッケージ構成を工夫する話があります。このへんは僕も開発標準を決めたりする時によくやりますが、こういう作業も大事なんだなと思います。

9章 アーキテクチャデザインスタジオを開く

　関係するみんなを集めてワークショップ的な集まりを開催し、作成→共有→批評を繰り返して設計を進めていく話。プロセスや進行のコツ、基本原則などもかなり詳しく書いてあります。こういうのはやったことがないのですごいもんだなあと思います。
　参加人数については7人を超えると効果が薄れ始め、10人が上限、3-5人が効果的とあります。ピザ２枚ルールを始めあちこちで語られる開発チームの人数の話とも関連しますね。
　各章の最後に出てくるLionheartプロジェクトも一度挫折しかけるのですが、このアーキテクチャデザインスタジオを経て考えがまとまって設計の選択肢が固まり、良い方向へ進んでいきます。マイクロサービスは結局採用を取りやめるようですね。チーム間でも共有意識が高まったとあり、あーやっぱり各自が自分ごとと捉えてやっていくアジャイル的な姿勢が大事なんだなと思います。

10章 設計判断を可視化する

　アーキテクチャー図のような絵を効果的に書いて人間の目に分かるようにし、そこから気づきを得ていく章。例がLionheartプロジェクトでの実際のコンポーネントになってくるので、具体的な技術が出てきてエンジニアでもイメージが掴みやすいと思います。コツはラフでも下手でもいいからまず図にしてみること、凡例を必ずつけること、基本は箱とそれを繋ぐ線でやってみることでしょうか。
　PowerPointの上手い資料の作り方ならそれこそ入門書は沢山ありますが、こうしたアーキテクチャ関連の図の描き方に触れている技術書はあまり見ない気がします。本章は何気に貴重かもしれません。
最初は精密さの低いラフスケッチでもいいんだよ、という例で画家の精密なウマの絵の横に作者さん自らによるヘタウマなウマの絵も掲載されています。このやり方はウマいですね。

11章 アーキテクチャを記述する

　できあがったソフトウェア・アーキテクチャを文書化していく話の章。冒頭にこれらの文書は概して悪名高く、読みにくかったり読まれなかったりして SAD: Software Architecture Description と略されたりで悲しみ(sad)である……とあります。エンプラ側に身を置く身としては、うん大企業っぽい読まれない巨大なドキュメントってあるよねと思います。(笑)

　モダンなアーキテクティングを目指す本書では形式的なドキュメントを書くのはどうしても必要な時だけで、最小限で書いていくこと、読み手や聴衆を意識して受け取る側が分からない言葉を使わないこと、などなど様々な工夫を述べています。
　なぜその設計判断を下したかの他に、逆になぜ選ばなかったのかも記録を残していくのが重要……とあり、ここは新たな気付きでした。映画ネタとしてはよく読むと『スター・ウォーズ エピソード6／ジェダイの帰還』がこっそり……！

スター・ウォーズ　エピソード6／ジェダイの帰還(字幕版)

12章 アーキテクチャに通知表をつける

　形になってきたアーキテクチャを評価したり課題を探っていく時の話の章。対象物を用意して会を開いてやっていくやり方、評価の観点やポイント、粒度などなど。従来のやり方だと設計レビューに相当するところです。
　ここでも設計フェーズの最後に1回巨大な長時間のレビューをやって指摘の嵐……ではなく、頻繁に継続的に少しずつやっていくのが良いとあります。明言されてはいませんがアジャイル的なアプローチですね。

13章 チームのアーキテクト力を強める

「現代のソフトウェアシステムにおいて、開発者とアーキテクトの違いはほとんどない」...

と冒頭にある最後の章では、アーキテクトが全部一人でやるのではなくてチームに判断の仕方を教えてみんなで決め、説明会やガイドを開いたりみんなで上手くやっていこう、みんなで成長していこう、という話。組織論やマネジメントの話によく出てくる「自己組織化」「権限移譲」のワードも出てきます。
　設計のテンプレートやコンポーネントのスケルトンになるサンプルコードを提供したり、チームメンバが安全に前に進んでいけるようにする工夫を教育の用語の「足場かけ」(Instructional Scaffolding) になぞらえています。WebフレームワークでいうとRailsやASP.NET MVCとかが備えているスキャフォールドの機能はまさにこれですね。
　僕も開発手順書をまとめたりサンプル機能を作って提供をしたりしますが、本書だとアーキテクチャのガイドレールというところが似ており、ああこうやって繋がっていくのかと納得します。

　通して例に出てくるLionheartプロジェクトも、方針の変更や仕様の変更を乗り越えて無事に成功して終わります。スプリング・フィールド市はこのシステムで年間100万ドルが節約できるとのこと。ヴァン・ダム市長もご満足でしょう。

第Ⅲ部 アーキテクトの道具箱

　後半1/3は作者さんの豊富な経験を生かしたデザインメソッドの道具箱。銀の弾丸へのオマージュとして「銀の道具箱」と呼ばれています。アーキテクティング上のいろんなことを解決していくアクティビティとして、様々な手法が紹介されています。
　ものすごく大雑把に言うとなんのことはなくお客さんにインタビューしているだけとか、何やらアジャイルの奥義的な面白そうなことをみんなでやってたり様々。それぞれに名前付け、所要時間や人数、準備、進め方などが整理されてきちんと言語化されて並んでいます。これは圧巻ですね。

14章 問題理解のアクティビティ

　ホワイトボードの前で付箋と一緒に議論したり、この辺は普通にありそうなやり方が様々、きちんと並んでいます。共通するのは参加者全員が自分ごととして捉えて協調してやっていく姿勢か。アジャイル開発で見かけるキーワードもよく出てきます。

15章 潜在的な解決策を探るアクティビティ

　面白かったのは「アーキテクチャの擬人化」というアクティビティ。これは日本人が得意そうですな…

16章 設計をタンジブルにするアクティビティ

　どうしてその設計にしたのか、後からでも見てわかるようにする道具箱。設計判断を記録しておく「アーキテクチャデシジョンレコード」というアクティビティは現場で役立ちそうです。
　一般の人を相手にアーキテクチャの要約を書いておく「アーキテクチャ俳句」という愉快な名前のアクティビティもあります。ダイアグラム図、シーケンス図も出てきて、昔はUMLという方式が有名でしたが今はこうして一部だけが残ったのだなあと思います。
　映画の小ネタとしてはクリスチャン・ベールが10代の頃に出演したミュージカル映画『ニュージーズ』がこっそり出てきました。

ニュージーズ [DVD]

　ベールというとバットマン三部作などが印象に残りますが、私的なオススメはトンデモB級ガンアクションの金字塔『リベリオン』を推したい…ガン=カタ最高！(なお異論は認めますw)

17章 設計の選択肢を評価するアクティビティ

　様々な切り口で選択をレビューしていく道具箱。カラーの写真も幾つかあり、きれいなペンとカラーの付箋のあるホワイトボードがこういう活動には必須のようです。やはりここでも共通するのはアーキテクトが1人でやるのではなく、チーム全員でやっていく所。

　アメリカではいけても日本では文化的に難しいんじゃないかな…とか社内のエンジニアにもお客さんにもアジャイルの文化が浸透していないと厳しいんじゃないかな…と思うようなアクティビティも中にはあるのですが、開発の現場でも応用できる手法が色々あると思います。

まとめ：モダンなアーキテクトとアーキテクティングへの地図とコンパス

　翻訳を担当された島田浩二さんのブログ記事に「地図とコンパス」と比喩されていましたが、まさにそれが手に入る本ですね。
　自分的には、本書で語られていることをまとめるとこんな感じになるかと思っています。

• モダンなアーキテクトは、象牙の塔で難しいことを考えてる孤高の人でも、なんか小難しいドキュメントを大量に書くだけの人でもない。
• チームを巻き込み、お客も巻き込み、人と協調して上手くやっていく。
• 技術とビジネス、両方と調和して上手くやっていく。
• 最強のアーキテクチャというのは存在しない。≒ No Silver Bullets. それはプロジェクトのコンテキストによって違い、その中で優先度づけやトレードオフを行って選んでいく。
• なぜそうしたかは大事だが、なぜそうしなかったかも大事。設計判断を残していく。
• 巨大な決断を一度にするのでなく可能な限り小さな粒度で判断を繰り返し、変化に対応できるようにする。
• 設計とは再設計であり、過去のパターンからの繰り返しで解決できることもある。アーキテクチャパターンや経験が役に立つ。
• チームメンバを育てる視点を持ち、自分を含めてみんなで成長していく。
• 唯一の正解はない世界なので考え続け、学び探求し続けることが大事。

　このへん、ソフトウェア開発の世界で一般的に名著良著と呼ばれる本を概観していくとだいたい本質的には同じようなことを言っていたりして、高みにある悟りの境地が見えてきた感、真理の泉が見えてきた感があります。

　「タンジブル」や「ルーブリック」など日本語で割と馴染みが薄い用語も時々出てきますが、それ以外は特に抵抗なく読み進められました。翻訳本特有の不自然な日本語はなくて読みやすいです。
　アーキテクチャ例の話ではHTTPにREST APIにNode.jsにマイクロサービスに…と技術用語もあれこれ出てきますが、同時に伝統のJava周りのキーワードもけっこう出てきて、やはり作者さんのようなベテランだと世代的に育ったのはこっちなのかなと思ったり。Ruby on Railsの名は本文中には、もしあなたがこのフレームワークしか知らなかったのなら…的な文脈で出てきたりしますね。

　また序文にもありますが、本書は完全にアジャイル寄りで第III部の道具箱にもアジャイルのキーワードがあちこち出てくるのですが、文中にはどこにも「アジャイル」の言葉自体は出てこないんですね。アジャイルの名を冠してもいなくても、変化に対応していく柔軟な姿勢はもう2010年代、2020年代の開発の現場のアーキテクティングには必須なのだなと思います。

　裏表紙にある通り上の段階に成長したいプログラマーの方にも、技術リーダーを目指す方にも、アーキテクト職を目指したり既にアーキテクトとして活動中の方にも、それぞれ様々なヒントが得られるでしょう。
　かくいうワタクシは事業会社でなくSIer(たぶん)のエンプラ開発の現場、どちらかいうとビジネス寄りの人も多い中で技術寄りの異端人物(w)としてアーキテクトっぽいことをしていますが、自分がやっていることと繋がる話もあればやれていない話もあり、新たな気づきがありました。

　純粋に技術的なアーキテクチャパターンや設計関連の本はあっても、ソフトウェアアーキテクトのあり方、マインド的なところまで含んだ本というのは最近の本ではあまり見ない気がします。そのへんの現代的なアーキテクトの振る舞い方、モダンな開発における現代的なアーキテクティング分かる良著でした。

関連記事のリンク集

翻訳を担当された島田浩二さん (id:snoozer-05) のブログ記事。 snoozer05.hatenablog.jp

翻訳レビュー参加された、アジャイルラジオのスクラムマスダーさん (id:scrummasudar) のブログ記事。 scrummasudar.hatenablog.com

勝手ながらネット上の感想記事リンク集。良い本だと思うのですが、それほど書評は多くないようです。ITエンジニアの総数の分母の中でもアーキテクトを目指す人は限られているからでしょうか。

• 『Design It!』を読んだ感想 - 虎の穴開発室ブログ
• 「Design It!」書評 | cloud.config Tech Blog
• 「Design It! プログラマーのためのアーキテクティング入門」感想 - えんたつの記録
• 「Design It!」書評～アーキテクチャ設計に役立つ4つのデザインマインドセット (アスキー) - LINE NEWS
• Design It! プログラマのためのアーキテクティング入門 | an Agile Way
• 読書メモ Design It! プログラマーのためのアーキテクティング入門 - Rso's Jotter
• https://www.imaharutech.work/entry/2020/01/04/234531
• 年末に読むオススメの技術書「Design It!」 - Alternative Architecture DOJO

読書会も催されています。

• デッドライン読書会#11「Design It!」（後半）の感想文 | 84zume Works
• デッドライン読書会#10「Design It!」（前半）の感想文 | 84zume Works
• Design It カテゴリーの記事一覧 - よしたく blog

関連書籍

　アーキテクティングとアーキテクト周りに関する本を上げてみました。国産の古めの本は除いてみます。

アーキテクトの本

『ソフトウェアアーキテクトが知るべき97のこと』は世界の様々なアーキテクトの方によるエッセイ集。この本は様子が分かってオススメです。前に感想記事を書きました。

iwasiman.hatenablog.com

ソフトウェアアーキテクトが知るべき97のこと

　ほか国産で日経BPの本、情報処理試験のシステムアーキテクト対策本などもありますが、やはりソフトウェアアーキテクトそのものを扱った本というのはあまりないような……？

アーキテクティングの本

　エンジニア界隈でみんな大好き『エンジニアリング組織論への招待』も組織論とかアーキテクティング周りの話はかなり共通するかと思います。

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

　ネット上であまり情報がなくて謎なのですが『モダン・ソフトウェアエンジニアリング』という本が2020年5月に出ています。翻訳は定評のある角征典さんだけど書評をまだ見かけないですね…

モダン・ソフトウェアエンジニアリング

アーキテクチャパターンの本

『エンタープライズアプリケーションアーキテクチャパターン』は本書の7章にいくつか挙げられているアーキテクチャパターンを、もっとたくさん載せて総説したような本。通称PoEAA、あのマーチン・ファウラー本です。日本語訳がちょっと読みにくいんですね…

iwasiman.hatenablog.com

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

『ソフトウェアシステムアーキテクチャ構築の原理 第2版』は大ボリューム、ちょっと古めの難しそうな本。

ソフトウェアシステムアーキテクチャ構築の原理 第2版

『アプリケーションアーキテクチャ設計パターン』も同テーマだと思われますが、いかにも国産SIer文化圏でJavaメインの内容だからか、あまり反響を聞かないですね。

アプリケーションアーキテクチャ設計パターン

特定のアーキテクチャパターンや手法の本

出ました『エリック・エヴァンスのドメイン駆動設計』はエンジニア界隈でもよく聞くDDD本。自分はKindleの奥底に積読してます！(おい)　DDDについてはより易しい入門書や技術同人誌がいくつか出ていますね。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

『Clean Architecture　達人に学ぶソフトウェアの構造と設計』もエンジニア界隈でよく名前が出てきます。プロダクトの改善にクリーンアーキテクチャを導入したり勉強を始めたという話題もよく聞きますね。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

2020年3月に出たばかりの『マイクロサービスパターン』も気になっています。

マイクロサービスパターン［実践的システムデザインのためのコード解説］ impress top gearシリーズ

マイクロサービスの名を知らしめたのが2016年の『マイクロサービスアーキテクチャ』で2017年の『プロダクションレディマイクロサービス』、2018年の『進化的アーキテクチャ』へ続きます。

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

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

進化的アーキテクチャ ―絶え間ない変化を支える

クラウド世界のアーキテクチャの本

　クラウドの雲海の世界にいくとアーキテクチャはこうなるよ、という話。
『クラウドネイティブ・アーキテクチャ』や『AWSによるサーバーレスアーキテクチャ』はそのうち読んでみようと思っています。

クラウドネイティブ・アーキテクチャ 可用性と費用対効果を極める次世代設計の原則 impress top gearシリーズ

AWSによるサーバーレスアーキテクチャ

　クラウド上のアーキテクチャを全体とすると、その中で個々のブロックはこんな工夫をして設計していけますよというのがクラウドデザインパターン。『Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版』と『Amazon Web Services 定番業務システム14パターン 設計ガイド』はAWS認定対策の一環で前に読んでみました。

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版（日経BP Next ICT選書）

Amazon Web Services 定番業務システム14パターン 設計ガイド

　AWSでなくMicrosoft Azureベースだと『クラウドデザインパターン　Azureを例としたクラウドアプリケーション設計の手引き』という本もありますね。

クラウドデザインパターン　Azureを例としたクラウドアプリケーション設計の手引き