<p></p>
<h2 id="%E6%A6%82%E8%A6%81"><a class="header-anchor-link" href="#%E6%A6%82%E8%A6%81" aria-hidden="true"></a> 概要</h2>
<p>「ソフトウェアテストをカイゼンする50のアイデア」</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__4731707b8e90a" src="https://embed.zenn.studio/card#zenn-embedded__4731707b8e90a" data-content="http%3A%2F%2Fwww.eijipress.co.jp%2Fbook%2Fbook.php%3Fepcode%3D2085" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="http://www.eijipress.co.jp/book/book.php?epcode=2085" style="display:none" target="_blank" rel="nofollow noopener noreferrer">http://www.eijipress.co.jp/book/book.php?epcode=2085</a></p>
<p>という本を読んだので感想についてメモする。</p>
<p>なお、かなり斜め読みしてしまったので内容が気になる方は自分で読んでみるのをおすすめします。テストに詳しく無いのであれば読む価値はあると思います。</p>
<h2 id="%E5%BE%97%E3%82%89%E3%82%8C%E3%81%9F%E3%83%8E%E3%82%A6%E3%83%8F%E3%82%A6"><a class="header-anchor-link" href="#%E5%BE%97%E3%82%89%E3%82%8C%E3%81%9F%E3%83%8E%E3%82%A6%E3%83%8F%E3%82%A6" aria-hidden="true"></a> 得られたノウハウ</h2>
<ul>
<li>抜け漏れを防ぐために他者とテストについて考えよ</li>
<li>定量化に努めよう</li>
<li>Given-When-Thenの順序は必ず守ろう</li>
<li>BDDでは以下の3つが重要となる
<ul>
<li>仕様</li>
<li>受け入れテスト</li>
<li>ドキュメント</li>
</ul>
</li>
<li>そのために、以下の3つを均衡させなければならない
<ul>
<li>仕様の簡潔さ</li>
<li>カバレッジの完全性</li>
<li>ドキュメントの統一性</li>
</ul>
</li>
<li>テストの優先順位をつけるにはAttribute Component Capabilityマトリクスが便利
<ul>
<li>理想的なACCマトリクスは「時間とお金があればどんな人でもテストできる」程度で抽象化する</li>
</ul>
</li>
<li>テストコードは書くためではなく読むために最適化せよ</li>
</ul>
<h2 id="%E6%84%9F%E6%83%B3"><a class="header-anchor-link" href="#%E6%84%9F%E6%83%B3" aria-hidden="true"></a> 感想</h2>
<p>正直抽象的なことが多くて読むのが苦痛だった。良い内容は書いてあると思うが、当たり前というか既知の内容も多く、それが抽象度高く書かれているという印象。なかなか実行可能で具体的なノウハウまでもっていくのは難しかった。</p>
<p>ただし、テストで思い悩むことがあった際にこの本に立ち返ると答えが書いてあるかもしれないので、薄く内容を覚えておいて読み返せるようにするのも手かもしれない。</p>


「ソフトウェアテストをカイゼンする50のアイデア」を読んだ

## 問題

iOSアプリにGoogle Analyticsを入れるとき、以下のように実装すると思う。

```
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
    ) -> Bool {
        FirebaseApp.configure()
        Analytics.setAnalyticsCollectionEnabled(true)
        return true
    }
}
```

Xcode 15.4でこれを愚直に入れたところPreviewがクラッシュするようになった。

## 解決策

以下のようにDEBUGではGoogle Analyticsを無効化することで解決した。

```
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
    ) -> Bool {
        FirebaseApp.configure()
        #if DEBUG
          // テストやプレビュー環境では Google Analytics を無効にする
        #else
          Analytics.setAnalyticsCollectionEnabled(true)
        #endif
        return true
    }
}
```

メインコードにDEBUGかどうかの分岐は極力入れたくなかったが、これ以外の解決策は自分には見つけられなかった。

誰かの参考になれば幸いです。

iOSアプリにGoogle Analyticsを入れるときはDEBUGではちゃんと無効にしよう

## 概要

オライリーの「プロダクションレディマイクロサービス」

https://www.oreilly.co.jp/books/9784873118154/

を読んだので、内容やノウハウをメモする。

## 全体感

UberのSREがプロダクションレディなマイクロサービスはどのようなものかについてチェックリスト的にまとめた書籍。

全体としては書籍の体は保っているものの、本当にチェックリストのようだった。

付録には本当にチェックリストという名目で箇条書きで掲載されており、確かにこれが網羅できていればプロダクションレディと言えそう。

一方で、これを全てやるのは至難の業。少なくとも日本国内だとこんなしっかりとしている企業は無いのではないかというレベル。

総じてイデア的に使うものであり、必要十分条件ではないと感じた。

(この書籍の内容が出来ていればプロダクションレディかもしれないが、プロダクションレディなサービスがこの書籍の内容を満たすとは限らない。)

## ノウハウ

本番対応の原則は以下の8つの項目である。

1. 安定性
2. 信頼性
3. スケーラビリティ
4. 耐障害性
5. 大惨事対応
6. パフォーマンス
7. 監視
8. ドキュメント

### 安定性

安定して動く、バグがない、のようなものではない。

CI/CDが整っているか、開発プロセスはわかりやすいか、など開発者目線での安定感が要点。

### 信頼性

テストは十分か、完璧なステージング環境があるか、カナリアリリースが行われているか、など。

### スケーラビリティとパフォーマンス

その名の通り。これらはまとめて語られていた。ボトルネックの明確化やキャパシティプランニングが適切に行われているかなど。

### 耐障害性と大惨事対応

これらもまとめて語られていた。単一障害点が無いこと、起こりうる大惨事が明確になっていること、障害対応手順の標準化など。

### 監視

ロギング、アラーティング、オンコールなどが適切に行われていること。ダッシュボードが整備されていること。

面白かったのは以下。

> オンコールランブックは、半分寝ている開発者でも難なくたどれるように書かれていなければなりません。

Susan J. Fowler. プロダクションレディマイクロサービス (p.233). Kindle 版. 

確かにその通りなのだが、「半分寝ている」という表現がちょっと面白かった。そんなランブックを書くことが果たしてできるのかという疑問は残るものの、やはり理想としては間違いない。

### ドキュメント

> 本番対応のよいドキュメントの目標は、サービスについての知識を一元的に管理するリポジトリを作って、メンテナンスすることです。共有すべき知識は、サービスについてのありのままの事実と、サービスが何を行い、組織全体でどのような位置を占めるかについての組織的な理解の両方です。そのため、ドキュメントが貧弱だという問題は、ドキュメント（事実）の欠如と理解の欠如の2つの下位問題に分けることができます。これら2つの下位問題を解決するには、すべてのマイクロサービスを通じてドキュメントを標準化するとともに、マイクロサービスについての理解を共有するための組織的な構造を用意する必要があります。

Susan J. Fowler. プロダクションレディマイクロサービス (p.224). Kindle 版. 

ドキュメントに関する項目があるのが非常に意外だった。他の項目は当たり前な部分が多いが、この項目に関しては新たな示唆が得られた気がする。

他にも引用しておくと以下のようにも書かれていた。

> 多くの開発者は、リポジトリ内にREADMEファイルを置くかコードにコメントをばらまいておけば、ドキュメントとして十分だと思っています。READMEファイルは必要不可欠であり、すべてのマイクロサービスのコードには適切なコメントが含まれていなければなりませんが、READMEは本番対応のドキュメントではなく、コメントはチェックアウトしてコード中を探し回らなければならなければ役に立ちません。

Susan J. Fowler. プロダクションレディマイクロサービス (p.226). Kindle 版. 

ドキュメントの有無は本当に大きい。「コードを読めばわかる」なんて表現は、個人的には場当たり的にコードを書く能力、時間しかありませんと言っているようなものだと思う。

例えばマイクロサービスとして利用している他チームのAPIを呼ぶ際に適切なタイムアウト値が知りたいとする。そんなとき「コードを読んでください」なんて言えない。API仕様書などの明示できるドキュメントが無ければ、利用者全員に対して個別に回答しなければいけないかもしれない。

全体として大規模なサービスになればなるほどマイクロサービスの利用者も増えるので、大手ほどこの問題が発生する可能性が高いはず。この書籍は全体的にそういう対象について議論しているように見える。

## まとめ

「プロダクションレディマイクロサービス」について感想やノウハウをまとめた。

誰かの参考になれば幸いです。

「プロダクションレディマイクロサービス」を読んだ

## 概要

芹澤 連 (著) の「戦略ごっこ―マーケティング以前の問題」

https://www.amazon.co.jp/%E6%88%A6%E7%95%A5%E3%81%94%E3%81%A3%E3%81%93%E2%80%95%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E4%BB%A5%E5%89%8D%E3%81%AE%E5%95%8F%E9%A1%8C-%E8%8A%B9%E6%BE%A4-%E9%80%A3/dp/4296204041

を読んだので、内容やノウハウをメモする。

## この記事で伝えたいこと

私は主にWebサービスを作っているエンジニアなので、個人開発する際にどのようにマーケティングすべきかについてこの本を読みながら考えた。

結論としては

***とにかく認知を取れ***

これだけ。データを見ると結局これに帰結する。特別なマーケティングの裏技なんてものは無い。

特に「どんな場面で想起してほしいか？」を考えて、そこをプッシュすることが重要。既存サービスと似ているサービスの場合、差別化部分より似ている部分をプッシュすることで最初は想起を得られやすい。

以降で少し詳しく書いているので時間がある方は読んでほしい。

## 書籍の感想

### 全体感

この書籍はマーケティングの基本として書かれている「購買ファネル」「顧客育成」「ブランディング」などに関して、論文などで科学的な方法で報告されている事実と、それ以外のお気持ちマーケティングを明確に区別して書かれている。

後者をやっても良いが、前者については単純に事実であることから、それを無視して後者をやっていても大した成果は得られないよね、という話をしている。

その上で、前者の科学的な成果をサーベイ的に報告しているのがこの書籍である。

### ダブルジョパディの法則

例えば、「うちは小さなブランドでニッチを攻めているので少ないロイヤル顧客に支えられている」は基本的に嘘である。真実は「小さなブランドは顧客数もロイヤルティも低い」で、大手と比べるとどちらも低くなる。

ロイヤルティだけを高めることはできず、顧客数とロイヤルティは常に一緒に動く。したがって、「小さいブランドはロイヤルティの高い顧客の満足度を高めれば顧客数が上がっていく」ということもない。

このように、どちらかが低い代わりにどちらかが高い、ということは無く両方とも低くなる、という事実をダブルジョパディと呼ぶ。

ほとんどのブランドに関して、ブランドの浸透率と購入回数は一定の曲線の上に乗ることが報告されている。

細かな差別化を行なってもこの曲線から逸脱して片方だけを伸ばすことはできない。顧客目線で差別化されている必要がある。

顧客はブランドではなく文脈で差別化している。我々がiPhoneを買うのは「下手に失敗したくないし、周りと同じものが良い」と思った時にiPhoneが思い浮かぶから買うのであり、iPhoneというブランドだから買うのではない。

### ユーザーの消費行動

特に消費財においては需要が先行する。すなわち、よく言われている

1. 注意
2. 関心
3. 欲求
4. 記憶
5. 行動

のような順序で発生するわけではない。

実際にはユーザーの行動はまず需要があり、その課題を解決するために想起される商品の集合からランダムピックされるような確率モデルで近似できる。

つまり過去の購買行動でヘビーとかライトとか分類することに大した意味はなく、ヘビーだからといって今後も大量に購入し続けてくれる証拠は全くない。ただの確率の揺らぎで、偏った結果が出たユーザーをヘビーとか呼んでしまっているだけである。

### 実際にやるべきマーケティング

ユーザーの想起集合に候補として上げられなければ絶対に購買されないし、他の指標もダブルジョパディの法則で達成できない。つまりはいかに多くの文脈で想起を得られるかがコアな部分となる。

したがって、現状リーチできていない層にリーチできる施策を行なったり、よく知らないユーザーが多い場合はまずは他のブランドとの類似点をプッシュし、そのブランドが買われる際に一緒に想起される状態にすると良いかもしれない。

また、ROIが良い施策だけやってれば良いというわけでもない。限界効用逓減の法則的にやればやるほど増分が少なくなっていく。したがって少しやってROIが良い施策をやっても思ったような効果は得られない。

## まとめ

「戦略ごっこ―マーケティング以前の問題」について感想をまとめた。

誰かの参考になれば幸いです。

エンジニアが「戦略ごっこ―マーケティング以前の問題」を読んだ

技術書典でサークルとして本を頒布するまでに必要な技術

RDBは集合、SQLは集合の操作

Cloudflare、Remix、OpenAI Embeddingsでニッチな投稿を優遇するSNS風サービスを作った


## 概要

中村昇著の「ウィトゲンシュタイン『哲学探究』入門」をAudibleで読んだので感想をまとめる。

https://www.audible.co.jp/pd/%E3%82%A6%E3%82%A3%E3%83%88%E3%82%B2%E3%83%B3%E3%82%B7%E3%83%A5%E3%82%BF%E3%82%A4%E3%83%B3%E3%80%8E%E5%93%B2%E5%AD%A6%E6%8E%A2%E7%A9%B6%E3%80%8F%E5%85%A5%E9%96%80-%E3%82%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%82%AA%E3%83%96%E3%83%83%E3%82%AF/B0BTLR8BNQ

## 感想

### ウィトゲンシュタインの思想

ウィトゲンシュタインというと、

> 語り得ぬものについては沈黙せねばならない

とか、

> 語の意味とはその使用である

とかが有名だが、全体的に「答えが出ない問題を考えても仕方なくね？ワロタ」みたいな感じがあって、それは考え方が似ていて共感があった。

### 自分との比較

ただ「語り得ぬもの」とか「語の意味」とかそういうものへの諦観が強いように見えた。

自分は広義の意味では決定論者で、所詮有限なこの世の全要素を記述すれば全てを記述可能なはず、という立場。

したがって、この世のatomicな要素を全て物理的に記述すれば確率的に「語り得ぬもの」は無くなるはず、と思っている。この点では少し見解が違った。

まあその上での有限なステートマシン的なものとして人間を見ている自分の方が、諦観が強い可能性もあるが……。

### 書籍自体の感想

また、解説者の思想が（入門書なので当然だが）出過ぎていたので、原著を読みたくなった。

自分の思想とウィトゲンシュタインの思想が似ていたのか、ウィトゲンシュタインから引用された文は全て非常にしっくり来たので、こういう変なやつはきっと入門書のターゲットではないんだろう。

そのせいで、途中で聴く気が無くなってきてしまった。

とはいえ解説自体はとても良いもので、英語とドイツ語の違いについての解説などの補足情報が非常に丁寧だった。

普段そういうことを考えてない人にはとても良い。 

自分も非常に参考になったことは明記しておく。

### Audibleについて

散歩中に本を読みたくてAudibleを使ってみたが、非常に良かった。

まず画面を目の前に持っていなくても良い。これだけで要件としては満たされていた。

倍速にできるのも個人的には非常にマッチしていたし、読み手の声も聞き取りやすい。

ラインナップが変な自己啓発本やビジネス書ばかりなのが残念で、もう少しちゃんとした本が増えるともっと使いやすいのにもったいないサービス。

## まとめ

総じてもう少しウィトゲンシュタインに踏み込みたくはなった。

厨二病のまま大真面目に成長してしまった自分としては、似た思想の人間を常に探している節があって、ウィトゲンシュタインは比較的近いかもしれない。

次は哲学論考かな。

「ウィトゲンシュタイン『哲学探究』入門」を読んだ

## 概要

技術書典にいい加減参加したく、こんなものを作った。

https://github.com/miketako3/teckbook-template

TechBoosterのRe:VIEWテンプレートを改変したものになる。Webエンジニア目線では使いやすいかもしれない。

## 技術スタック

- Re:VIEW
  - 誤解を恐れずにいえばLaTexのラッパー
  - 技術書を描きやすいらしい
  - markdownっぽい形式の.reファイルを書いてPDFに変換できる
- VSCode
  - Re:VIEWの補完ができる拡張機能がある
  - 本当はIntelliJが良かったが…流石にプラグインを作りたくは無い
  - devcontainerは便利ではある
- Dev Containers
  - VSCodeの機能
  - Dockerを使って開発環境を構築する
  - Re:VIEWのDockerイメージが公式に配布されているのでそれをベースにすれば楽ちん
  - ということで元々のテンプレートからそのまま持ってきた
- GitHub Actions
  - 元々のテンプレートではCircleCIで校閲、Github ActionsでPDF作成としていたが、慣れや使い勝手もあり全てGitHub Actionsに変更した
  - Github前提となるので、GitLabなど用のファイルは全て削除した
- textlint
  - 文章の校閲ツール
  - スタンダードな技術だと思っているので採用した
  - PR時に自動的に実行される
- reviewdog
  - textlintの結果をPRコメントに表示してくれる
  - さすがにコメントが無いと使いづらいので採用した

## 感想

これでやっと書けるわけだが、書くまでに手間がかかりすぎる……。

もっと楽に書ける環境があると参入障壁が下がるのになーとなる。

自動校閲とか自動バージョニングとかをいい感じに入れたSaaSがあって、技術書典とか印刷会社とかとシームレスに連携できたら最強な気がする。

## 参考

https://reviewml.org/ja/

https://review-knowledge-ja.readthedocs.io/ja/latest/

https://github.com/TechBooster/ReVIEW-Template

https://zenn.dev/karaage0703/articles/52be7d25f7d76b

https://zenn.dev/b0b/articles/reviewdog_textlint_ga_tested

技術書典に向けて執筆環境を整えた

ヘルスケアデータをGrafanaで見たくない…？〜健康 Reliability Engineering〜

## 概要

このブログのドメインを含む2つのドメインをGoogle DomainsからCloudflareに移行した。

## はじめに

昨年10月に[ドメイン管理サービスをお名前.comからGoogle Domainsに移行した](/posts/domain-service-change)ばかりだったが、なんとGoogle Domainsが事業売却されるとのこと……

https://www.itmedia.co.jp/pcuser/articles/2306/16/news083.html

仕方ないので、今回はCloudflareに移ることにした。ちょうどWorkers等も話題になっていたし。

## 移行時のTips

### 移行作業

特に何も言うことはない。Cloudflare側のサイトとしてドメインを登録しておけば、後は案内に従ってネームサーバーの変更、移管を進めるだけで良い。

あまりにも簡単だった。本当にこういうのは嬉しい。

### ERR_TOO_MANY_REDIRECTS

移管後、ブラウザでドメインにアクセスすると、ERR_TOO_MANY_REDIRECTSというエラーが発生した。

オリジンがhttpsであるにも関わらず、CloudflareのSSL設定がFlexibleになっていたことが原因だった。オリジンにはhttpでアクセスして戻されてを繰り返していたらしい。

Fullにすることでオリジンまでhttpsで通信するように設定できるので、それで解決した。

![Cloudflareの設定画面](/domain-service-change-2/img.png)

## 移行後の感想

Google Domainsと比べると以下の不満はある。

- Google Cloudとの連携がない
- ドメイン管理以外の機能が多い

まあ前者は仕方ないし、後者はそれはそれでメリットもあるので良しとした。

## まとめ

ドメインをGoogle DomainsからCloudflareに移行した。

正直Google Domainsが事業売却されるのは寝耳に水で、今後何を信じてサービスを選べば良いかわからなくなる……。

上手くいかなかったサービスを手放すのはGoogleのお家芸ではあるが、そんなに採算取れてなかったんでしょうかね？

Cloudflareも今は波に乗っているが、いつかはGoogleと同じ道を辿るのかもしれない。そういう意味では日本企業のサービスを使う方が安定性は高いのかも。

何はともあれ皆さんのドメイン管理サービス選びの参考になれば幸いである。

ドメイン管理サービスをGoogle DomainsからCloudflareに移行した

LangChainにおいて記憶を日本語で保持する

Raycastでローカルのパスワード管理をしちゃおう

## 概要

オライリーから出ている 「ソフトウェアアーキテクチャ・ハードパーツ」

https://www.oreilly.co.jp/books/9784814400065/

を読んだので、重要な章を抜き出してノウハウをメモする。

と言いたいところだが、重要な部分が多すぎるのでこの記事では書きやすい部分だけを抜き出している。

書籍の内容を拾いきれているとは到底言えないので、是非読んでもらいたい。

ある程度システム設計に明るく、アーキテクチャに課題を抱えている人にはぴったりな内容になっていると感じた。

## 1章 「ベストプラクティス」がないとどうなる？

全ての解決策はトレードオフである。

> アーキテクトは、自分の問題に対する「銀の弾丸」を探し求めてはならない。

アーキテクトの問題はそれぞれユニークなため、ベストプラクティスが存在しない。

だからこそ「ハード」パーツである。

- 難しい問題
- 堅い、システムの土台となる部分

> 決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないトレードオフの組み合わせを狙おう。

多くのアーキテクチャにおいて、データこそが全てである。

アーキテクチャデシジョンレコード（Architecture Decision Records：ADR）（https://adr.github.io）を記入せよ。

アーキテクチャ統制のため、アーキテクチャ適応度関数を設計、運用せよ。

## 2章 ソフトウェアアーキテクチャにおける結合の見分け方

結合の定義

> 一方の変更が他方の変更を引き起こす可能性がある場合、ソフトウェアシステムの2つの部分は結合している。

結合を発見、分析し、トレードオフを評価せよ。

アーキテクチャ量子の定義

> アーキテクチャ量子とは、高度な機能的凝集、高度な静的結合、同期／非同期による動的結合を持つ、独立してデプロイが可能なアーティファクトを指す。アーキテクチャ量子の一般的な例には、あるワークフロー内の整ったマイクロサービスなどがある。

これはすなわち、データベースを共有しているアプリケーションは全て1つのアーキテクチャ量子である。

## 4章 アーキテクチャの分解

モノリスからサービスベースアーキテクチャを経てマイクロサービスへ移行していく上で、2つのアプローチが紹介されている。

- コンポーネントベース分解
  - まずはリファクタリングし、モジュールを分けていく。
  - 分けられたモジュールをサービスに切り出す。
- 戦術的フォーク
  - まるっと別アプリケーションとしてコピーして立て、それぞれ1部の機能しか使っていない状態にする。
  - その後、不要な機能をリファクタリングによって削除していく。
  - コンポーネントベース分解と比べて
    - メリット
      - 事前の分析が不要なので作業開始が早い
      - コードは抽出するより消す方が簡単 (と書かれていたが本当か？)
    - デメリット
      - 不要なコードを消す努力が必要
      - ロジックは汚いまま

## 6章 業務データの分解

データベースを分けるか？分けないか？もトレードオフである。

データを分解する要因として以下のようなものがある。

- 変更制御
  - カラムの変更等の影響が多岐にわたる
- コネクション管理
  - 1つのデータベースだけを使うとコネクション数の管理が難しい
- スケーラビリティ
  - コネクション数
  - 容量
  - スループット
  - パフォーマンス
- 耐障害性
  - 1つのデータベースだけを使うとデータベースが単一障害点となってしまう
- アーキテクチャ量子
  - 1つのデータベースだけを使うと1つのアーキテクチャ量子となってしまう (つまり独立してデプロイできない、等)
- データベース種別の最適化
  - 1つのデータベースだけを使うと1つの保存方法だけしか使えない (つまりデータ特性ごとに最適な選択肢が取れない)

逆に、データを統合する要因としては以下のようなものがある。

- データ関係
  - 密結合な外部キー等があるか？
- トランザクション
  - 単一のトランザクション単位が必要か？

モノリスなデータベースを分解するには5段階のプロセスを踏むと良い。

1. 分析し、ドメインを特定する
2. ドメインごとにテーブルを割り当て、移動する
3. コネクションをドメインごとに分離する
4. スキーマをそれぞれのデータベースに移動する
5. コネクションを切り替える

## 7章 サービスの粒度

マイクロサービスの粒度を大きくするか？小さくするか？もトレードオフである。

粒度を小さくする要因としては以下のようなものがある。

- サービスの範囲と機能
  - 凝集性が高い状態になっているか？
- コード変動率
  - 一部のコードだけ変更頻度が高くないか？
- スケーラビリティとスループット
  - 一部だけスケールする必要があるか？
- 耐障害性
  - 一部の故障で全体が故障してしまわないか？
- セキュリティ
  - 一部だけ高いセキュリティが必要か？
- 拡張性
  - どの程度拡張されるか？

粒度を大きくする要因としては以下のようなものがある。

- トランザクション
  - サービスをまたいだトランザクションが必要か？
- ワークフローとコレオグラフィ
  - サービス同士がやりとりする必要はあるか？
- 共有コード
  - サービス同士がコード共有の必要はあるか？
- データ関係
  - データは分解できるか？

## 9章 データの所有権と分散トランザクション

サービス間で共有するデータが存在するとき、どちらのサービスが所有権を持つのか、どのように共有データを管理するのかをトレードオフによって決めなければならない。

分散トランザクションはACID特性をサポートしないため、代わりに結果整合性を検討せよ。

## 10章 分散データアクセス

所有していないデータにサービスが読み取りアクセスするためには様々な方法があり、その間にもトレードオフがある。

- サービス間通信パターン
  - サービス間がWEB API等で通信してDBを隠蔽する
- 列スキーマレプリケーションパターン
  - 非正規化する
- レプリケーションキャッシュパターン
  - 分散キャッシュする
- データドメインパターン
  - 愚直に一緒にDBを見てしまう

## 11章 分散ワークフローの管理

分散システムどうしを調整する方法については基本的には2種類あり、トレードオフがある。

- オーケストレーション
  - 調整役を別途立てる
- コレオグラフィ
  - 最初のサービスが調整役となる

## 12章 トランザクショナルサーガ

通信、整合性、調整についてそれぞれ2パターンあり、組み合わせると合計8パターンのサーガ (アーキテクチャの大別) がある。

| パターン名       | 通信  | 整合性   | 調整         | 結合度   | 複雑さ   | 応答性/可用性 | スケーラビリティ |
|-------------|-----|-------|------------|-------|-------|---------|----------|
| エピックサーガ     | 同期  | アトミック | オーケストレーション | とても高い | 低い    | 低い      | とても低い    |
| 伝言ゲームサーガ    | 同期  | アトミック | コレオグラフィ    | 高い    | 高い    | 低い      | 低い       |
| おとぎ話サーガ     | 同期  | 結果整合性 | オーケストレーション | 高い    | とても低い | 中程度     | 高い       |
| 時間旅行サーガ     | 同期  | 結果整合性 | コレオグラフィ    | 中程度   | 低い    | 中程度     | 低い       |
| ファンタジーサーガ   | 非同期 | アトミック | オーケストレーション | 高い    | 高い    | 低い      | 低い       |
| ホラーストーリーサーガ | 非同期 | アトミック | コレオグラフィ    | 中程度   | とても高い | 低い      | 中程度      |
| パラレルサーガ     | 非同期 | 結果整合性 | オーケストレーション | 低い    | 低い    | 高い      | 高い       |
| アンソロジーサーガ   | 非同期 | 結果整合性 | コレオグラフィ    | とても低い | 高い    | 高い      | とても高い    |

## 13章 コントラクト

ハードパーツとしてのコントラクトの定義は以下である。

> アーキテクチャの部品が情報や依存関係を伝えるために使用するフォーマット。

コントラクトとして例えば以下の様なものがあり、トレードオフがある。

- 堅い
  - 例
    - gRPC
  - メリット
    - 型
    - バージョニング
    - 検証が用意
    - ドキュメント
  - デメリット
    - 密結合
- 緩い
  - 例
    - JSON
  - メリット
    - 疎結合
    - 進化しやすさ
  - デメリット
    - 型がない
    - コンシューマ駆動契約等の適応度関数が必要

帯域幅は無限だと思うな。

## 15章 独自のトレードオフ分析を構築する

MECEに分析せよ。

技術の過度な売り込みを避けよ。

> 何かを伝道する立場をとってはいけない。トレードオフに立ち返ろう。

> 銀の弾丸を追い求めるのではなく、トレードオフを分析するスキルに磨きをかけることで、アーキテクトは組織に真の価値を提供できるのだ。

## まとめ

アーキテクトというふわっとした分野において地に足ついた良い本だった様に感じた。

全てはトレードオフである、というのは自分も読む前から感じていたことではあったため、裏付けが取れて嬉しい気持ちになった。

そして、そのトレードオフをこれでもかと投げつけてくる本書は実際にアーキテクチャを考える上で非常に参考になるだろう。

最近「マイクロサービスって間違いだったんじゃね？」等が話題になったりもしたが、そういうことに振り回されず淡々とトレードオフを分析できるエンジニアになりたい。

「ソフトウェアアーキテクチャ・ハードパーツ」を読んだ

「Googleのソフトウェアエンジニアリング」でわかるリファクタリングと自動テスト

## 概要

このブログのドメインを含む2つのドメインをお名前.comからGoogle Domainsに移行した。

## 移行理由

### お名前.comのUI/UXが悪い

異論がある方はいないと思う。それくらいお名前.comの使い勝手は悪い。

どのメニューがどこにあるのかが一見してわからないし、ログインするたびにドメイン期限を更新しろとうるさい。

あまりにも体験が悪く、サーバー等を一緒に借りるのでなければお名前.comでドメインを取るのはおすすめできない。

### メールが有料

お名前.comではメール転送やメールサーバのレンタルは有料となっている。後者については別に良いのだが、前者についてはあまり好ましくは無い。

この点、Google Domainsならばメールの転送が無料で行える。以下の記事が非常に参考になった。

https://www.value-domain.com/media/domain-usage-mail/

お名前.comでもメールは年間1000円/ドメイン程度ではあるが、それでも無駄なコストはカットしておきたいだろう。

## 移行後の感想

非常に快適である。まず不要なメニューが存在しないため、UIがシンプルになっている。

さらに、天下のGoogleのサービスである。日本の一企業であるGMOに比べれば信頼性は非常に高まっているだろう。

自分がドメインに対してそこまでリッチなサービスを求めていないかもしれないが、現状でも必要十分な機能が存在しており、Google Domainsで不足を感じる人はまずいないと思っている。

## まとめ

ドメインをお名前.comからGoogle Domainに移行した感想を述べた。

今後ドメインを取得する際はGoogle Domainsを使っていきたいし、他者にもおすすめできるサービスだと感じている。

皆さんのドメイン管理サービス選びの参考になれば幸いである。