[アーキテクチャ]と[設計]の違いアーキテクチャのほうが上位（e.g. micro service architecture）設計（デザイン？）の方が下位（e.g. domain driven design, design pattern）というふわっとしたイメージがあるらしいがそういうの線引きできるものでもないし区別することに意味ないよねってクリーンアーキテクチャに書いてあった。>ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

[アーキテクチャ]の本を読んだりしていると何か「正しい実装」というようなものがあるような気がしてしまうけど、実際のところ[銀の弾丸はない]のでその時々の状況によってベターなアーキテクチャというのは変わってくる。これはアーキテクチャに限らず現実の問題や[意思決定]全般に言えることで、複数の選択肢があってそのうちどれを選んでも成功する場合があれば、どれを選んでも失敗する場合もあるが、人間は選択肢を与えられると「どれかが正解である」と思いたがる性質があるので注意が必要。（もちろん自分も人間なので例外ではない）（この性質は学校教育による後天的なものなのだろうか）

https://docs.wantedly.dev/いずみんさんはWantedlyでリードをやっているらしい#アーキテクチャ

>アジャイル開発のアーキテクチャに対する基本スタンスは最初に先読みをしすぎた設計 (Big Design Up Front) をしないということだ。> ...> BDUFは良くないとしても、NDUF (No Design Up Front) はあまりにもリスクが高い。私たちは、ENUF (Enough Design Up Front) を目指しているのだ。p. vii>大切なことは、最良のアーキテクチャは、その文脈によって変わるということだ。文脈なしにアーキテクチャは成立しない。このことを強く思い出させるエピソードを1つ紹介しよう。Twitterは最初Ruby on Railsで開発されたが、2009年ごろからJVM (Java VM) ベースのアーキテクチャに移行し、レスポンスとスケーラビリティを改善した *1。 途中で大きくアーキテクチャを変更した巨大な商

[API設計ガイド https://cloud.google.com/apis/design?hl=ja] #Google[API設計 https://docs.microsoft.com/ja-jp/azure/architecture/best-practices/api-design] #Azureアーキテクチャセンター[通信 https://github.com/donnemartin/system-design-primer/blob/master/README-ja.md#通信] #システム設計入門

https://kenfdev.hateblo.jp/entry/2020/01/13/115032こういうの過去に何度か調べてるけどあんまりまとまった情報がなかったので助かる[ACL][RBAC][ABAC]

マイクロサービスアーキテクチャでつくっていると既存のサービスに依存しないのを１個生やせばいいので新規の機能開発がしやすい。あと売り切りじゃなくてサブスクリプションでお金をとっていると常に追加の開発費が生まれるのでそこもフィットしている感じがする。#アーキテクチャ

リアルタイムで実行する必要があるのは何かどれぐらいのレイテンシを許容するかどれぐらいの整合性を担保するかどれぐらいの規模になりそうかどんな形式のデータとして使いたいか

ポジションを取ることで唯一無二なプロダクトができる。#アーキテクチャ

https://docs.microsoft.com/ja-jp/azure/architecture/クラウド関連のアーキテクチャが色々載っていて良さげアーキテクチャ関連で知らない用語をググるとよく出てくる。Azureアーキテクチャ

[技術が進歩するとUIが変わる]し、DBも変わる。RDBMSが生まれてしばらくはRDB一択だったけど、[技術が進歩するとUIが変わる]に書いたように大量のユーザが同時にアクセスするようなユースケースが生まれる時代になるとRDBではクエリを捌ききれなくなって、NoSQLという分野が立ち上がってきた。[CAP定理]を基にして必要な性能を選択する文化が生まれた。アプリケーションとしてはDBに依存しない抽象的なデータモデルを定義して、それを実装するような形式でDBアクセス層を実装しておくと求められる性能が変わった場合にDBを変えやすくなる。

[マルチモーダルにするとUIが増える]と同じような感じ。もともとはPC向けのネイティブアプリケーションだったものが、インターネットの発展と共にWebアプリケーションになり、スマートフォンの発展と共にスマホアプリになり、スマートスピーカーの発展と共に音声アプリになり、、、

視覚を使って情報を提供する場合聴覚を使って情報を提供する場合組み合わせて情報を提供する場合etc...色々あるし、今後増えていくかも。

https://aws.amazon.com/jp/solutions/case-studies/irobot/#AWS#アーキテクチャ

Command Query Responsibility Segregationcommand: 書き込み系の操作(副作用あり)query: 読み込み系の操作(副作用なし)を分けて実装する[アーキテクチャ]正確性を求められるのはCommand

大抵は四角とか矢印とかで関係を表現するんだけど、四角が何を指しているのか（サーバ？クラス？マイクロサービス？）矢印が何を指しているのか（依存？継承？Publish？Subscribe？）がわからなくなるので、凡例にちゃんと書いておく。#アーキテクチャ

>LinkedInでは大きく2つのデータを扱っている．1つはウェブサイトから集められる大量のユーザのアクティビティデータ．これらをHadoop（バッチ処理）を通して機械学習しレコメンド/ニュースフィードなどサービスの改善に用いている．それだけではなくこれらのデータはサービスの監視（セキュリティなど）にも用いている．2つ目はシステムのログ．これらをリアルタイムで処理してサービスのモニタリングを行って>

経営は[マクロなアーキテクチャ]エンジニアリングは[ミクロなアーキテクチャ]そもそも大きい枠組みで目指す方向性が間違っているといくら小さい枠組みで工夫してもあまり意味がなかったりする。というかむしろ頑張れば頑張るほど世の中が悪くなったりすることもあると思う。[転職の思考法]では個人の能力うんぬん以前にそもそも儲けられる仕組みがあるところで働くかどうかのほうがサラリーに効いてくるというようなことが書いてあったけど、これに近い。