---
tags: Fundamentals of Software Architecture
---

# 全部ここに書く

## What's this?

ソフトウェアアーキテクチャの基礎2,3章を読んで、話したいこと、気になること、わからなかったところを本読み会で話せるようにメモしておく

## メモり方

- (p.999)おにぎりがだいすきなんだなぁ(もくお)
- それってどゆこと(たかゆき)

みたいな感じ
ルール変えてよし
誰が書いたかって後からわかるんですかね　人が書いたやつは名前出る説

## メモ

### 2章 アーキテクチャ思考

- (p.23)アーキテクチャと設計の違い→開発者とアーキテクトの違いってことか（たなか）
- (p.24)アーキテクトと開発者の双方向・サイクリックな関係。やっぱり反復で正解を探し続けるの大事(たなか)
- p.24 アーキテクトと開発者が実質1つのチーム。これはできてないところ多そう(宮田)
- P25 アーキテクトと開発者って明確に分業しているスタイルが一般的？アーキテクトってアプリかインフラかどっち寄りなんだろう。（いなどめ）
- メインフレームだとインフラがやっているイメージ。アプリは従うだけ。（いなどめ）
- オープンはアプリ寄りなイメージ。上手く言語化できないけど。（いなどめ）
- （p.25）アーキテクトは幅(たなか)
- 個人としてはつまみ食い好きなので、そういうのが親和性とかあるのかな（tanaka）:+1:
- 専門性の陳腐化への対応先→幅？（たなか）
- 幅の広げ方をどうするか（tanaka）
- 幅を広げる勉強会・コミュニティがあるといいのかな。シナジー（たなか）
- 24章に、1日20分だけ勉強しよう、SNSコミュニティに入ろう、って書いてますね（宮田）
- P28 アーキテクトとして持つべき深さのレベルが分からない。。幅が大事と言いつつきっと自分が思っているより数段上の深さも求められてるような気がする。（いなどめ）:+1:
- P29 知識の獲得方法を変えるとは？各方面の情報を効率よくアップデートできるような情報源が欲しいな。ある？（いなどめ）
- P33　セキュリティとかも全部広くわかってないとトレードオフ判断できないよね（たなか）:+1:
- 自分の考えに自信持てるように相談したいよね（たなか）
- p34　アーキテクトもコード書くべき。ｲｲﾈ!（たなか）:+1::+1::+1: :+1:
- 良いアーキテクトと良いチームは持ちつ持たれつでやってこうね〜（たなか）:+1
- p35　出た！PoC！（たなか）
- 速攻でやれるほうがいいよね〜（たなか）
- エンタープライズだと難しいところあるよね〜多分。どうですか？（たなか）
- そもそもこういった類はPoCとして決裁するのが至難の業。権限者がやってみなければ評価できないことを理解できない問題。識者に聞けば答えがあると思っている問題。（いなどめ）
- :-1:

### 3章 モジュール性

- p３７　モジュールとは？教えて偉い人。（たなか）
- クラス・関数集合/パッケージ/可視性/スコープ（たなか）
- p39 モノリスがよくわかってない。教えて偉い人。（たなか）:+1:
- p41　この辺大事だし、よく読むしわかるけど、すごく活用できるかというとうーん（たなか）
- 計算式あってばりムズイ。この辺いるんかな笑（たなか）
- P45 分析ツールが色々あるっぽいが、この辺普通にみんな見ているもんなんだろうか。意識するのは一定の規模以上かな？（いなどめ）
- p.46 主系列からの距離 むずい。(宮田)
- 
- p.49 コナーセンスって初めて聞いた。(宮田)
- ｐ４９　コナーセンスは割と分かりやすいし、普段の意識の言語化がされている。（たなか）
- 見える化したいなぁ（たなか）
- https://github.com/masuda220/code-inspection ???的な??（たなか）
- ただp54的なこともあるのか…（たなか）
- P52 リファクタリングってこんなに観点があるもんなんだな。奥深い。（いなどめ）
- p.54 メトリクスは低レベルという問題(宮田)
- アーキテクトからすると、メトリクスを計測して解釈してリファクタリングするのは開発者に自発的にやって欲しいってことよね。低レベル領域なので。
- アーキテクトと開発者が1つのチームになって解決するのかな？メトリクスを計測したい旨を開発者に理解してもらって、計測ツール選定や提案から開発者に託すとか。
- p55　モジュールとコンポーネントの違い（たなか）:+1:

というか続きも読めてれば先行してメモしていけばいいのでは:+1:

### 4章 アーキテクチャ特性

- p.58 分類ありがたい。実務で考えやすい [name=みやた]
- p.59 どこからを「大量のアーキテクチャ特性」と呼んでいるのか [name=みやた]
- 場合による ってか？
- yes! [name=もっくま]
- 証券取引とかはすごいspeedもとめられるよね〜とか？
- 5章につながるかも
- お客さんとのコミュ大事
- お客さんは100%ってそらいうよね
- p.61 あんまりLocalizationとかはアーキとしては意識してなかったけどたしかに感 [name=もっくま]
- p.63 標準化された完全なリストは存在しない。ときたもんだ。 [name=みやた]
- p.63 このアーキテクチャ特性の一覧を客観的に網羅されているものをずっと探していたけれど、それを如何に過去の経験などを踏まえて、出せるかがアーキテクトの腕の見せ所と言われたことあるけど、なるほどその通りなのかと改めて思った。不明確で曖昧なのは世界共通認識なのか。　[name=いなどめ]
- p.65 > アーキテクトであれば誰でも感じる不満は、ソフトウェアアーキテクチャ自体を含む、とても多くの重要なことについて、明確な定義がないことだ [name=みやた]
- 逆にすこし自信を持てた。いつも何を考慮したらいいんやっけ？って悩みながらやってるけど、みんな曖昧なところで頑張ってるんやね。
- p.65 用語に基づく誤解の問題は根深い。組織で独自のユビキタス言語を使うとそれはそれで社外との乖離が大きくなったりして、混乱することも多い。浸透させるためのドキュメントも膨大になりがち。ここにもトレードオフが存在する　[name=いなどめ]
- p.66 最悪でないアーキテクチャ→ｲｲﾈ! [name=もっくま]
- イテレーティブなアーキテクチャ設計が必要になるわけだけど、どないすんねん？って感じ
- 5章から戻ってきたけど、カスタマイズ性よりはパフォーマンス性のほうが、後戻りしやすい、とかはあるかもとかは思った。
- ちょっと別観点ですけど、ノーコードツールで運用→スケールしてきたのでガラポン、ってときにまぁまぁ依存度が高くて辛み、みたいなところがあるなと思っている。特に認証情報周り。
- そもそもノーコードでのアーキテクチャ特性保証って要件によっては難しいところ出そうだよね
- p.66 アーキテクチャをイテレーティブに設計する、ってエンタープライズで適用できているところってどういう意思決定構造になっているんだろうか。従来型の開発プロセスが存在している企業では、難しいように思う。　[name=いなどめ]

設計はぐらついている？

### 5章 アーキテクチャ特性を明らかにする

- p.67 汎用アーキテクチャはだめ　[name=もっくま]
- 反論したいわけじゃないけどリファレンスアーキテクチャはあるよね。盲目的に採用するのはだめだけど。
- p.67 アーキテクチャ特性は絞るべし。絞るためにはステークホルダーと協力して、ということだけれど、実際ステークホルダーは直接的な目の前の要件に対してだけの話であり、将来来るであろう要件の先読みとそれも考慮したような話ができる人はほぼいないのでは。でもシステムにはそれも求められるから汎用に振りがちだったりするように思う。　[name=いなどめ]
- 先読みはできない、故にアーキテクチャはイテレーティブに設計できるようにしよう、っていう記述がどっかにありましたね [name=みやた]
- 5章より先かも。忘れた。 [name=みやた]
- p.68 ヴァーサ号＝初手MSA　[name=もっくま]
- p.68 特性ライキングではなく大事なもの3つ選び。なるほどね。　[name=もっくま]
- p69で既に3つ以上重点とか言ってるけど？
- 3つに絞る理由は合意取れないからです、とかお客さんに説明できないからここもドメイン語翻訳がほしかった[name=honda]

- p.68 ドメイン関心事とアーキ特性の翻訳むずそう　[name=もっくま]
- p.70 アーキテクチャ・カタ　[name=もっくま]
- みんなカタ好きだね
- https://nealford.com/katas/
- ↑例題やってみても面白そうだなと思った
- シリコンサンドイッチもほんまか？という感じ。みんなで考えてみたい。
- というかシリコンは要件が曖昧すぎる。PO呼んできてほしい。
- まぁ改めて考えるとそんなもんか…という感じ。課題としてはまぁまぁeasyな気も。
- ぼくも面白そうと思います！ [name=みやた]
- p.72 明示的な特性と暗黙的な特性に分けよう　いい指針かも [name=みやた]
- p.75　なんでフランチャイズだとコスト制約やアーキテクチャに影響があるの [name=もっくま]
- それな [name=みやた]
- p.75 犠牲的アーキテクチャ　初耳　完全に理解した [name=みやた]
- p.78 まとめると「アーキテクチャ特性を絞る」とはアーキテクチャ特性の重要度（強さ？）を明らかにする、ってことでおK？ [name=みやた]
- 例えばパフォーマンスを全く無視するとかじゃなくて、

### 6章 アーキテクチャ特性の計測と統制

- p.79,80 具体化・ユビキタス言語化ｲｲｽﾈ[name=もっくま]
- 7980ページの本は厚さおよそ40cmだそうです[name=みやた]
- :thinking_face: [name=もっくま]
- p.80 サーバーレスで画像multipart処理のファイル容量上限に引っかかってめんどくさい事があったなあ[name=もっくま]
- p.80 AWSでもなんか普段と違う挙動を勝手に見てくれるアラートありましたよね[name=もっくま]
- [これかな](https://aws.amazon.com/jp/blogs/news/new-amazon-cloudwatch-anomaly-detection/)
- [可観測性](https://www.splunk.com/ja_jp/data-insider/what-is-observability.html#:~:text=%E3%82%AA%E3%83%96%E3%82%B6%E3%83%BC%E3%83%90%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3(%E5%8F%AF%E8%A6%B3%E6%B8%AC%E6%80%A7)%E3%81%A8%E3%81%AF%E3%80%81%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE,%E3%81%82%E3%82%8B%E3%80%8D%E3%81%A8%E3%81%BF%E3%81%AA%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82)
- とってはいる
- ただみんなで見るとか活用できてない
- 気軽に誰でもみれている状態にしておくのすごい重要
- ex)マーケ指標
- 行動変容を促す
- いろんなベンダーツール
- datadog,newrelic,dynatrace,mackerel,,
- いろんな特性あるよね
- p.80 >高度なチームは...パフォーマンスの数値を...統計分析に基づいて定める
- こういうメトリクスをキチンと取ることをなんて言うっけ。〇〇性って言わないっけ[name=みやた]
- メトリクスをきちんと計測してダッシュボード化してメンバー全員が気にする文化、必要だが後回しになりがち説[name=みやた]
- p.81 サイクロマティック複雑度よく言われますね、というかこれ以外しらんけど[name=もっくま]
- このあたりの計測ツールがjavaすげぇ、他の言語向けのやつがない、という感じで計測ツールの知見がほしい
- [これしかしらない](https://www.sonarqube.org/)
- CCは[ESLintでも測れて](https://eslint.org/docs/rules/complexity)閾値ルールをきめれますね[name=みやた]
- どうでもいいけど先日測ってみたら20くらいのクラスあってわろた[name=みやた]
- ESLintできるんだすげぇ
- p.83 設計手法としてのTDDいいよね。凡人のための最適解はここだと思っている[name=もっくま]
- p.83 アジリティの計測はどうするんですかね[name=もっくま]
- 単純なシステム・アーキテクチャ以外の組織的な要因も影響しそうだなとか思ったり(ex:デプロイ申請→リリースまでで23日かかる的な)
- p.88 ArchUnitへーという感じ[name=もっくま]
- [適当記事](https://qiita.com/daisuzz/items/f33b4e02bb3f5fdbc048)
- 限界あるですが、このあたりのアーキテクチャについてrailsとかのリッチフレームワークはある程度レーンを敷いてくれるので、そのあたりはまぁまぁええですよね、と最近思います
- 動的型付け言語なのでそんなに好きじゃないですけど…
- 「SPA+RESTが当たり前になっている -> 小さめのアプリだとバックエンド側薄くなりがち -> React(Vue知らない)はレーンを敷いてくれない -> フロント側が複雑化しがち」はあるある？[name=みやた]
- p.88 >アーキテクトは開発者に適応度関数の目的を理解してもらった上で
- だいじ[name=みやた]
- p.89 [カオスエンジニアリング](https://aws.amazon.com/jp/builders-flash/202110/awsgeek-fault-injection-simulator/?awsf.filter-name=*all)興味ある[name=もっくま]
- https://github.com/Netflix/security_monkey
- AWSとかに吸収されてるんですね
- 総論、適応度関数とか指標を適切に計測して、不味そうなら進化的アーキテクチャ的にadjustしていこうね、でいいんですか[name=もっくま]
- この見える化は盲目的な改善ではなくスクラム的な透明性・検査・適応に根ざしたリファクタのために必要なアプローチである、というオレオレ意見

### 7章 アーキテクチャ量子と粒度

- p.94 アーキテクチャ量子は腹落ちがすごい[name=もっくま]
- 独立デプロイ可能/機能高凝集/依存同期処理で境界線が引ける
- p.95 ”マイクロサービスでは各サービスに独自データベースが含まれる”よく言われますね。[name=もっくま]
- どうせ今後出てくるんでしょうが、前から気になってたこととしてはデータ2重持ちとかになったりしないんですか？
- SSOT(Single Source of Truth)にして都度都度参照する感じですか？
- その通信の瞬間は動的依存がある感じ？
- データはある程度2重持ちになると思います。ただしデータの内容は同じだけど意味は異なると思います。[name=みやた]
- その上で、何らかの理由で2重持ちを許容し難くSSOT等するのであれば、参照/被参照しているサービス同士は同期的なコナーセンスになる
- 従ってドメインモデル上はコンテキストが分かれていたとしても、システム上は両者の統合を検討すべき、が本書の解釈だと思った
- p.118に"アーキテクチャスタイルの基本的な決定は、設計プロセスの中でアーキテクトが発見したアーキテクチャ量子の数に依存する"とあるため。
- p.95 "量子のコナーセンス"をコナーセンスの枠組みに押し込むのは無理がないか？ｗと思いつつ、言いたいことはとても納得感ある[name=みやた]
- p.96 の図よくわからんので解説ｵﾅｼｬｽ[name=もっくま]
- p. これまたカタがわからん笑[name=もっくま]
- p.97 こういう事例の話、どの本読んでても正直理解するのつらい[name=みやた]

### 8章 コンポーネントベース思考

- p.101 モジュールの物理的表現＝コンポーネント[name=もっくま]
- モジュール/コンポーネント/パッケージ/ライブラリ？
- jar、gem→モジュールをパッケージングしたのがライブラリ？
- モジュール…関連するコードの集まり
- コンポーネント…モジュールが物理的にパッケージ化されたもの
- ライブラリ…コンポーネントの１種で関連コードをより高次にまとめたもの
- p.101 コンポーネントという言葉はよく使うけど、人によって指すものが違うから、前提を合わせないと噛み合わないことが多々ある[name=いなどめ]
- 直訳すると「構成要素」だから何にでも使える言葉
- コンポーネントの定義もアーキテクトの役割
- p.103 開発プロセスとアーキテクチャは独立している[name=もっくま]
- デプロイとかは影響を与えるので例外
- 関係あるやんけ！
- プロセスって変えれる？
- ガチWF
- 開発ぷろせすが変えれないというよりは、承認プロセスを変えられない
- ここがボトルネックになると :zany_face:
- 独立してるので、別個考える
- 関係者で色々DOcとか整備して認識揃えるの大変
- 必要ならやろう
- 内部設計とかコードの書き方まですり合わせるの無理じゃね？
- 描いてるうちに変わるよね？
- コードレビューで抑える
- レビューで無理なとこは計測結果でFBする
- p.103 要件がどこから発生したかどうかを気にしない[name=もっくま]
- アーキテクチャ特性とかの決定要因だから気にするのでは？？？
- p.104 アーキテクチャ、技術から見るか？ドメインから見るか？[name=もっくま]
- ドメイン領域が複雑ならドメインから、シンプルそうなら技術から
- MicroServiceの1サービス内のアーキテクチャはどうなん？とか思った[name=もっくま]
- p.105 コンウェイの法則により、最上位にレイヤードアーキテクチャを採用すると組織構造もレイヤードになる[name=みやた]
- するとDevSecOpsやりたい、フルサイクルエンジニアリングやりたい、という時に、組織の壁が障害になりがち
- 従って(少なくとも最上位は)ドメインによる分割をやりたくなる-
- p.107 ドメインによる分割単位でサービス分割して、サービス毎に技術による分割でレイヤ構成するのが当たり前くらいに思っていた[name=いなどめ]
- 最初の決断となるけれど、他にどんな選択肢があるのだろう？
- p.108 8−7の技術による分割の図が謎[name=もっくま]
- ここのLocalってなんなんやろ
- packageかな
- にしてもようわからんな
- p.109 職能横断チームはそんなにうまいことできないのでは笑[name=もっくま]
- 人がいなさそう
- p.109 ドメインによる分割の方がメリット多くないか？ほんまか？[name=みやた]
- 機械学習使う〜とか、そういう技術特性からモジュールとサービスを分けるとかもあり感[name=もっくま]
- p.110 > 開発者は、アーキテクトが設計したコンポーネントを完璧なものと捉えてはいけない[name=みやた]
- このコミュニケーション重要
- 開発者もアーキテクトも、設計に完璧はないため相互に継続議論すべき、と認識しないとうまくいかない
- 特に、アーキテクトにそのつもりがなくても、開発者は「完成した設計がアーキテクトから降りてきた」と捉えがちな印象
- p.111 ロールや責務を分析する→どういうフォーマットで描くんかな、クラス図？ [name=もっくま]
- p.112 コンポーネント発見のアプローチ
- [EventStormingをやってみた話 \- Qiita](https://qiita.com/98lerr/items/9b1c50348dcaa925e1a5)
- ちょっと具体例に辿り着けなかった
- p.113 エンティティとCRUDだけで成り立つようなアプリはもはやノーコードで作れるようになった気がする。Railsすらいらん[name=もっくま]
- p.118 こんな要件のアプリ作ったことないなぁ[name=もっくま]
- それでも開発開始から完全に色々分割するの厳しい気がするので、一旦モノリスで作り始めつつ、切り出しがうまいことできるアプローチを取りたいな〜
- 後、ドメインもわかるし各サービスの技術もわかる神みたいなのが必要そう
- p.118 > 基本的な決定は、設計プロセスの中でアーキテクトが発見したアーキテクチャ量子の数に依存する[name=みやた]
- アーキテクチャ特性の違いが、分散システムを採用するか否かの基準の１つになる！なるほどな～
- p. [name=]

## 第Ⅱ部 アーキテクチャスタイル

### 9章 基礎

- 歴史っぽい [name=もっくま]
- p.127 基本はモノリスor分散[name=もっくま]
- p.128 クソほど考慮事項あって無理ゲー感[name=もっくま]
- p.128 「ネットワークは信頼できない」はビジネスやPdMまで含めると共通認識ないがち[name=みやた]
- 「APIエラー率99%です。1%エラー原因は不明です。たぶんネットワークの問題です」に対して「一応原因調査して」って言われるパターン
- p.129 平均レイテンシを把握する→分散アーキが実現可能か判断する唯一の方法[name=もっくま]
- よくわからん
- そのネットワークパフォーマンスとアーキ特性が合わないかを判断できるってこと？
- とりあえず可観測性大事
- p.129 平均レイテンシを把握するのが分散アーキテクチャ実現可能性につながる話について、[name=みやた]
- 具体的な利用技術の選定につながるということかな？
- 分散システム作るとして、Lambda使うのか、コンテナ使うのか、ネットワークはどこで区切るのか、等々色々あると思うが、それぞれilityが異なるはず
- p.129 スタンプ結合の解決方法の例示５つがよくわからない。。[name=いなどめ]
- この辺のところってクラウドだとハードウェアがなかったり、ある程度サービスに乗っかれば補償できるとかないんですかね [name=もっくま]
- 知らないことを知らないことが漠然と多そうという不安がある[name=いなどめ]
- p.131 「値駆動契約」って何？検索してもいまいち出てこない[name=みやた]
- p.135 結果整合性ってチェック処理走らせたりするんですか？[name=もっくま]
- 金融とかの勘定系とかは必要な場面ありそう
- なんかDynamoDBとかの結果整合性しか見ませんとかを思い出すなどした
- p.135 分散ロギングはダイレクトサービスのオープンとホストの関係でもやってる気がする[name=いなどめ]
- 通信は違うし、ある程度密結合だけども分散システムな側面は今でも普通にあったりするな
- p. [name=]
- p. [name=]
- p. [name=]
- p. [name=]

*※なんかページ書くのだるいからやめてみます*

### 10章 レイヤードアーキテクチャ

- p. なんか↑はいわゆるアプリ内の階層アーキという理解なのだが、その層ごとで異なるチームが見る、なんで事あんのか？[name=もっくま]
- p. デプロイメント単位がプレ層とビズ層で分かれるとかあんのか？[name=もっくま]
- p. 開放レイヤーと閉鎖レイヤーなるほど。意識的でないけど無意識的にそうしてそう。[name=もっくま]
- p. 開放レイヤーってどこがどう開放されているかを管理しきれなさそう [name=honda]
- p. モノリス大好き！[name=もっくま]
- p. よっぽどでなければこのアーキテクチャでいい[name=もっくま]
- p. アーキテクチャシンクホールは要するにDBとかの内容そのままfetchするということ？何が悪いんやろか[name=もっくま]
- そんなことするくらいならエクセル使えみたいなこと？笑
- hasura.ioとかSupabaseとかそんな感じがきそ基礎になりますよね
- p. [name=]

### 11章 パイプラインアーキテクチャ

- p. シェル芸思い出す[name=もっくま]
- ShellScript組むときはパイプすごい意識する・普通のプログラムと違う考え方ですすめるのは感覚わかる
- p. このアーキ、変換処理とかに特化してる感じ？[name=もっくま]
- 普通のアプリではサブシステム的にしかなさそう
- kafka使わないからわからない
- kafkaで色々組み時には意識する、ということなのかな？ただのメッセージングやと思っててそんな工夫ないと思ってた
- https://logmi.jp/tech/articles/325337 こういうロギング系とかには絡むのかな[name=もっくま]
- p. このへんデータサイエンス系の人のほうが触れてそう (ﾁﾗｯ)[name=もっくま]
- p. kafkaってなんだ[name=honda]
- p. [name=]

### 12章 マイクロカーネルアーキテクチャ

- p. Eclipseなるほど[name=もっくま]
- これもいわゆるWebアプリでは意識しないのかなぁ
- p. ライブラリ的にjar突っ込んで拡張・ロジック対応する、でおｋ？[name=もっくま]
- p. 「マイクロカーネルアーキテクチャ」でggってもこの本のことしか出てこねぇ[name=もっくま]
- p. レジストリ…プラグインに関する外部参照される情報のまとめるところ？[name=もっくま]
- p. コントラクト…ただのインターフェースの話？[name=もっくま]
- p. 昔のパッケージはこんなことしてたんですかねぇ[name=もっくま]
- p. なんかRedHatのワークフローエンジンの話おもいだした[name=もっくま]
- p. 「マイクロカーネルアーキテクチャ JIRA」で調べてもでてこなかった。どのへんなんだろ[name=もっくま]
- p. Wildflyだと…？[name=もっくま]
- p. [name=]

### 13章 サービスベースアーキテクチャ

- サービス毎にデプロイを分けるのかな？
- サービス内はレイヤードなんだ
- p171のマイクロサービスとの違い
- オーケストレーションか
- あとtxの整合性
- デプロイの影響
- スキーマ変更の影響はマイクロサービスでは独立したDBだから影響ない？
- でもドメインで必要なデータは変わったりしそうやけど
- エンティティの共有はおもろい
- 荒さの粒度がなんとも､､､
-
- サービス指向アーキテクチャのことかと思っていたけれど、違うって認識であってる？
- 同じこと思いました。
- [ESB](https://www.otsuka-shokai.co.jp/words/esb.html) とセットでよく言われる
- 似てる？
- このサービスベースアーキテクチャにはESB出てこない。よりライトなもの？
- ESBがあるかないかで複雑度が変わる？
- サービス同士の通信がなさそうなもの＝サービスベースアーキテクチャ
- SOAの定義が書いてる本によると、フロント・サービス・サービスリポジトリ・サービスバスによって形成されるもの、らしいので、やっぱり定義上は違うものとして良さそう
- １３−３と１３−４を足した感じ？
- ESBだと腐敗防止層的なデータのトランスパイルするような役割もあるので、そういう差もある
- 粒度の粗いドメイン。。。
- マイクろサービスとの違いは大きくDB共有によるtx管理のしやすさ
- データベースは共有しているけれど、サービス毎に使用しているスキーマ異なるなら、分けてもOK？共有ライブラリと関係ないものたちを共有するメリットが何かある？
- 分かりやすくマイクロサービスって言ってるだけで、実態はサービスベースアーキテクチャになっているものってそれなりにあるような気がしている。これくらいがちょうどいいのでは。。

### 14章 イベント駆動アーキテクチャ

- 複雑な業務システムに向いてそう
- リクエストベースモデルの場合は、ノードを階層に分けたりメッシュ・フローを組むのは無理そう
- ドメインではなくて技術で分かれてるんや、Orderとかが分かれているから？
- そもそもの分け方の発想が技術志向な感じ
- モノリスからここに発展する余地を持っておくには？
- ブローカーの終端イベントは必要になってから足しても別にいいのでは？
- メディエーターみたいな中央集権的なところがあった方が管理しやすそう
- jBPMとかあったなぁ普通にワークフローで使ってたはず
- ネットワークの設計や問題発見がだるそう。マネージドでカバーされてるといいのかな
- ブローカーとメディエーターのイベントの性質の違い面白い
- エラー処理　監視ツールみたい
- エラーのフロー処理実装　宣言的に書いたりするのかな？
- データロストしていいケースなんかあるんかな？
- ブロードキャストのニーズは負荷分散？
- 量子サイズの決定が気になる
- パフォーマンスへの弾力性を持たせることとかできるのかな
- 確かに全体的にどうなっているのかを把握するのは難しそう
- イベントツリー図見てみたい
- ggってもでてこねぇ
- ブローカーを断片的に採用するのは確かに簡単にできていい。やったこともあるし。
-
- これも各サービス（プロセッサーたち）は中身はレイヤード？
- オーケストレータは製品？スクラッチ？
- ワークフロープロセッサーでエラーを取り除いて再度キューを投げ込むとあるけれど、エラーって取り除けるものなのか。。。？予期できているものを扱ってるだけ？
- 設計の成果物って何が一般的なんだろう。イベントツリー図？
- 自分で実装したことないからイマイチ雰囲気理解になるな。宮田くんの具体例に期待。
https://qiita.com/dairappa/items/fd136a98cab98c517673
- インターフェースとかガッチリ設計期間とかとっていい感じにしないと実装できなそうだけど、そこんとこどうなの？アジャイルや！っつって適当にできんの？
- キューだけだと辛い
- リクエストキュー・リプライキュー
- kafkaga主流
- キュー(トピック)は基本消えない
- 残っている旨味は？
- 思想としてどのtopicがそのサブスクライバーが読んでもおっけー→コンシューマーを追加しやすい
- 構造が違う
- 競合？
- SQS？
- 中央にメッセージングの設計を置くことが明確ならkafka
- アーキとして見越せるはず
- 簡易に用途が決まってる場合はキュー
- 安上がりだし
- デス・スターアーキテクチャ
- キューとサブスクライバーの定義をMQに持つ必要があるものが多い
- どんどん増えていく
- kafkaだと1つに集約できる
- kafkaは単一障害点になるかもなので冗長化しないと行けない
- kafka採用観点
- 良さそう
- PoC
- コストもおkそう
- https://developer.mamezou-tech.com/blogs/2022/02/28/debezium-cdc/
- DBの更新を勝手にイベント拾ってくれる
- モノリスからMSに切り出したときに、モノリスの更新イベントをMSでひろう
- Confluentたけぇ

### 15章 スペースベースアーキテクチャ
- 初めて聞く名前のアーキテクチャ。解説見てもこれまで見聞きしたもので合致するものない。
- テスト容易性とシンプルさがトレードオフで犠牲になっていることから、保守がゴリゴリに入るプロダクトには適さない印象。
- そうじゃないプロダクトってあるんですかね :thinking_face:
- Webアプリケーションのスケーラビリティに限界があるのは伝わったが、図15-2がぱっと見で複雑そうで辛そう印象
- こんなに複雑にしてまで大規模かつ応答速度を求めるサービスって世の中に数えるほどしかないと思うが、どこが採用してるんやろう
- 要するにインスタンス間でメモリ共有できる謎技術＋DBの前にキューイングしてるってこと？
- これで普通の3層構造でスケールアウトするときとのメリットの差がわからん
- あードメインサービスに分割しつつ、情報共有をメモリで非同期にやろう的な？
- かえってめんどくせぇ
- 基本DBのデータはインメモリキャッシュしとくってことか、はえー
- なんかブロックチェーンアプリの設計みたい
- [世界一のブロックチェーンゲーム『マイクリプトヒーローズ』を支える技術スタックとサーバ環境 \- ログミーBiz](https://logmi.jp/business/articles/321418)
- 衝突のところ、インメモリでｔｘ管理できないから、衝突回避はどうするんやろか。衝突確率・数が少ないからおｋ、ではないとおもうんやが
- 向いてるユースケース人数1万人なんや
- 実際チケットサービスとかでやってんのかな
- サーバーレスやといかんのか
- 高いんかな
- そもそもこのアーキも高いらしい
- いちおうすごく複雑なドメインにも対応できそうではあるけど
- にしても人類には早すぎるくらい複雑
- 要考慮事項多すぎそう
- コンサートチケット販売システムに衝突は許されなさそうだもんなぁ
- 予約処理と決済処理のアーキテクチャを分ける、とかでクリティカルな障害は避けられる？
- 特性評価のところすごい怖いことしか書いてない笑

### 1６章 オーケストレーション駆動サービス指向アーキテクチャ
- 時代の文脈ときた
- なんかクラウドができた〜とかの時代背景が各アーキどこまで見てるのか知りたい。なんなく感覚と合わない感。
- 章の冒頭で無用の長物になってしまったって言ってしまってるww
- :face_with_open_mouth_vomiting:
- サービス指向アーキテクチャはそれはそれとして廃れながらも考え方としては成立していて残っているアーキテクチャだと思っていたけれど、モノリスと分散の両方の欠点が含まれているものとして、消えていったというのが正しいのか。
- カスタマーサービスを共通で切り出すとかマイクロサービスでは絶対やらない考え方だな。マイクロサービスのアンチパターンがサービス指向か。
- サービス指向アーキテクチャも分散アーキテクチャなので、Webのブログとかの浅い説明を読むとマイクロサービスに似てるな等と感じてしまう。再利用性を最重要視する分散モノリスと呼ぶ方が正しいんだな～と再確認できた。
- 終始悲しいことしか書いてない
- そもそもこういうエンプラのシステムがゲロ吐くほどむずかしいってことやないか
- 解決策の一つはマイクロサービスってことでおｋ？
- これはアーキテクチャーパターンの1つと言っていいのか…？

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

- むっず
- 多くの開発者は「マイクロサービス」という言葉を説明でなく戒律と捉えてしまい、細かすぎるサービスを作ってしまう
- 確かに最初そういう印象を受けてた
- マイクロという言葉で未だに誤解を生む
- 再利用よりも複製を優先する
- 業務ロジック観点だとこのトレードオフが一番悩ましい
- コレオグラフィってどういう意味？
- 語源
- しばしば「振り付け」と翻訳される。コレオグラフィは「踊ること」と「書くこと」を意味する二つのギリシア語に端を発する言葉であり、その意味において、踊りを記譜することである。
- 書籍"マイクロサービスアーキテクチャ"より
- コレオグラフィ p.50
- あるサービスで起きたイベントを契機に、他のサービスのプロセスを実行する手法の1つ。サービスが非同期にイベントをPublishし、他のサービスがSubscribeすること。対比的な手法にオーケストレーションがあり、こちらはあるサービスが直接的に他のサービスを呼び出すこと。
- ここまで書いて、p.260に解説があったことに気づいた。。
- 一度の開発で完璧な粒度を発見することはほとんどない、故にイテレーションを回すのだとのこと
- それが一番大変だったりするんだよなぁ。。
- 初期に粒度が決まらないことによる弊害との向き合い方も難しい。。
- エンティティの罠ってなんだっけ？
- データモデルをドメインモデルと勘違いすることか
- データ分離のところ、データ分離の手段、大まかに2つ
1. あるドメインのデータはそのドメインに問い合わせる
2. レプリケーションやキャッシュを用いてデータ自体を分散させる
- 後者は重複が多いから初見は筋悪に見えるが、ケースバイケースということですね
- サービスメッシュ、雰囲気しかわからん
- https://www.alpha.co.jp/blog/202205_01
- https://www.redhat.com/ja/topics/microservices/what-is-a-service-mesh
- https://www.redhat.com/cms/managed-files/service-mesh-1680.png
- マイクロフロントエンドって結局どうやってやるんや
- 夢物語み
- ここのAPI層ってBFF？GraphQLとかでいい感じにするんですかね
- https://zenn.dev/neko3cs/articles/introduction-to-micro-frontends
- icestarkとかいうフレームワークがあるのか
- https://zenn.dev/mikana0918/articles/344861f49f7190
- ユーザーごとにフロントエンドを分けたりもしますよね
- マイクロフロントエンドって、UIコンポーネントの組み立ては誰の責務？
- といったようなことから流行らなかった？
- https://docs.microsoft.com/ja-jp/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout
- 結合より重複を好むなるほど
- 適切な境界のガイドライン
- 目的
- tx
- コレオグラフィ
- とは？
- https://zenn.dev/tatta/books/4e993c596e7dc9/viewer/4700fb#%E3%82%B3%E3%83%AC%E3%82%AA%E3%82%B0%E3%83%A9%E3%83%95%E3%82%A3
- 数珠つなぎコール
- ダメな例
- もう１例のオーケストレーションってStepFunctions的なこと？そこを親にして呼び出す感じ？
- あー局所的なメディエーターってことか
- イベント駆動との違いはメディエーターとかの後続処理として連携する、としないこと？（グローバルなメディエーターを持たない）
- ドメインと技術の切り方
- サービス間通信の同期非同期
- メディエーター欲しいよね
- 線引き（モノリスからマイクロサービスへ）
- クソ複雑やけどマイクローサビス粒度に分離できない、みたいなドメインあるのかな
- 各サービス内のインフラ意思決定で揉める・時間かかるとかあるとだるそう
- 決定権はチームにほしい
- ネーミングサービス？
- p256 なにこの図
- コンソール？
- ファルシのルシがコクーンでパージ
- サービスディスカバリーの実装例って何ですか？
- サーガパターンなるほど
- 一旦保留して全体コントロールするってことでいいすか
- メルペイかどこかの決済でサーガパターン駆使している話聞いたことあるけどとてもやりきれる気がしない
- サーガ初めて見たとき「障害点何個あんねん無理やろ」って思ったけど、Outboxでできるよ的な記事見てできそうな気がしてきた
- https://www.infoq.com/jp/articles/saga-orchestration-outbox/
- 実際問題すごいいい感じに独立してサービス毎にリリースできるってあり得るんですか
- ドメインの整理・見える化ってどうしてます？
- コンテキストマップ、ドメインモデルマップ

### 18章 適切なアーキテクチャスタイルを選ぶ

- 新技術へのキャッチアップ大事
- 最近なんか興味あるのあります？
- 流行りの延長線＋業務上の研究兼ねて、NFTとかUnityとか。。。新技術ではないか。。迷走中。
- cluster
- UnrealEngine
- overspec気味
- https://forbesjapan.com/articles/detail/46273
- https://dfinity.org/
- 分散化具合の把握ってできるのか
- https://www.coindeskjapan.com/160473/
- ERモデルってやっぱり有能
- 人間がわかりやすくモデルを整理できる
- 最近NoSQL設計したんですけど、ひとまずERで概念整理した
- p274 草
- まさかダイレクトに否定する記述があるとわww
- ヘイト
- 標準的にはやっぱり同期通信倒しなんすね
- 後で進化する用？
- 本にすると後に引けない？
- 世の中の人がついていけない
- 人間に扱える複雑度
- ADR最近やってる
- p279 やっぱりマイクロサービスとイベント駆動のちがいよくわからん
- p281 基本はアーキテクチャ量子とマイクロサービスって一致するよね？

### 19章 アーキテクチャ決定

- p286 グランドホッグデーアンチパターンなりがち
- 特に上が決めて下が従うような構造のときになりやすい気がする
- 蒸し返されそう
- Pjに必要
- アーキテクトとかきちんとしたロールでやりたい
- スキル感的に間に合ってないまま突き進むことが多い
- 過去の議論経緯が出せない
- p292 ADRは一度チームでやってみました
- 粒度が難しい
- フォーマットが薄くて書きやすい一方、例えば "決定" には決定事項だけでなく根拠やトレードオフも書いて欲しい等、書く内容の認識合わせは結局必要
- ちょうどよく薄っぺらい
- 共有・後追いしやすい
- かけない？
- 素人でやってみた、という意図が少なくともわかる
- 後から何も根拠なかった、という事がわかる
- 比較軸ができる→ちょっと試す、という過程を踏むと思うが、そもそもの比較軸を適切に出せていない気がする
- 比較対象をだすの難しいよね
- コンサルは比較対象出してくれる
-
-

### 20章 アーキテクチャ上のリスクを分析する

- 総論、リスク分析は一人ではできっこないから皆で議論しようね、ですか
- [ほう（TSのArchUnit）](https://silverbirder180.hatenablog.com/entry/2020/11/28/120833)

### 21章　アーキテクチャの図解やプレゼンテーション

- まず手書き
- https://www.microsoft.com/ja-jp/microsoft-365/visio/flowchart-software
- https://www.omnigroup.com/omnigraffle/
- レイヤー意識したことなかったなぁ
-　draw.ioとかでもあるのかな？意識したことない
-　https://www.archimatetool.com/
-　https://note.com/hiramoto/n/n8030dd3eceec
-　
- 確かにステークホルダーに説明するスキルはアーキテクトには求められる
- 結構、技術あっても説明弱い人いる印象
- 相手を意識して、納得させる説明
- そもそもむずい
- draw.io
- で描いて、svgエクスポートして、git管理

### 22章 効果的なチームにする

- 22-1の図の意味の無さ
- 実装のレベル感というか、チームで合わせて実装するの難しいよね
- しかしながら、キャッシュが最適なケースもあると思うし、開発者がそうしないケースもありそう
- refinementのタイミングでセットベースは広げて共有しておきたい
- 兼任がいいんですかね？
- 少なくとも距離は近いほうがいいよね
- アーキテクトが開発してないケースで良かったケースあんまりないのかも
- チームの成熟具合を見ながら手入れ具合を調整していく
- 結局これ
- ケースバイケースすぎるww
- 短納期の場合アーキテクトは邪魔というのは面白い
- プロセスロスちゃんと勉強したい
- 多元的無知
- ライブラリ・FWの選定むずかしいよね
- 枯れがち
- 結構開発リードっぽいような感じのイメージを感じた
- 結果、何でもできないと駄目なのね…
- 登大遊さん思いだした
- 研修では実践レベルにならない
- 研修レベルの難易度はできる
- ないところ
- 認証・他システムとの絡み・セキュリティとかまで見れない
- 泥臭いところができない
- チーム育成・交渉
- 制約を明らかにできない・難しい
- 優秀な人は残らない
- 金
- 技術的な挑戦的な仕事

### 23章 交渉とリーダーシップのスキル

- そんなパーセンテージの見極めできるんか
- まぁやろうと思えばできるんか？
- 金融庁の基準、外的基準を参考に
- りーがるっぽいところ知りたい
- 業界による
- 自分たちのシステムだと、運用の中で模索しながらやっていく
- SLA売ったほうが魅力的
- 他社比較
- 当たり前品質・魅力品質
- 人の意見を認め、尊重し、能動的にコミュニケーションするの大事ですね
- トレードオフスライダー作っても面白そう
- Why大事
- 抜け落ちがち
- 非同期コミュニケーションだと特に大事
- やっぱりみんなが優秀じゃないと成立しないよね、とは思った
- 開発者自身で正解を導き出してもらう、とか
- それぞれがスペシャリストである前提ですね、日本だと、、、
- 議論したくない人もいそう
- developerとarchitectはやっぱり違うロールなので、いきなり議論しろと言われても…というのもありそう
- それでもしゃべんのは大事だな
- 開発者は複雑さに惹かれる、のか…
- 優秀なアーキテクトは手本を示す
- ステークホルダーへの交渉もできて開発もリードできるスーパーマン見たことない
- 人の名前を呼ぶこと
- 信頼貯金大事
- そういえばSLCで新人来たときに握手したらみんなに笑われたな
- ありがとうとかは意識するようにはしている
- スリダールいいヤツ
- こんなうまくいかんやろ笑
-

### 24章 キャリアパスを開く

- 確かにいずれは死んでいく知識を得ているよなぁ
- でもどんなものでもそうだよなぁ
- 20分ルールいいなぁ
- このチームでやってみます？:+1:
- 毎日投稿的な:+1:
- 朝かーまぁいけるかー:thinking_face:
- https://www.infoq.com/
- https://www.thoughtworks.com/radar
- https://dzone.com/refcardz
- エコーチェンバー
- ソーシャルメディアを利用する際、自分と似た興味関心をもつユーザーをフォローする結果、意見をSNSで発信すると自分と似た意見が返ってくるという状況を、閉じた小部屋で音が反響する物理現象にたとえたものである
- パーソナルレーダー
- 皆さんどうしてます？
- 作ってないなーでも作ってみるのはありかもしれない
- 今全社の人材育成考えないと、、、という感じ、使えるかも
- 分類まではしてないなぁ
- SNSがんばろうかなぁ
- 最近は言い訳が勝つなぁ…
- エッジコンピューティング
- WASM
- 関数型プログラミング