yojikのブックマーク - はてなブックマーク

マイクロサービスアーキテクチャは大変という話 - pospomeのプログラミング日記
最近「マイクロサービスって大変だな」と感じることが多いので、書いてみた。単なる感想です。 pospomeのマイクロサービス歴面倒なのは技術ではないモノリスだと厳しい楽しくもある宣伝 pospomeのマイクロサービス歴以下の企業で7年ほどマイクロサービスに携わっている。 DeNA（ゲームプラットフォーム）メルカリ（認証認可基盤） DMM（DMMプラットフォーム） DeNA, メルカリではサーバサイドエンジニアとして仕事をしていて、 DMMではプラットフォーム事業本部という120人のエンジニアが在籍する開発組織のアーキテクトとして仕事をしている。それぞれの会社で開発の規模感、開発体制、自分の役割などが異なるので、直接比較できないが、やはりポジション的に今のDMMが一番大変だなーと感じる。面倒なのは技術ではないマイクロサービスというと "分散トランザクション" とか "通信
yojik 2023/07/11
リンク
Apache Bench でヘッダーを設定する - pospomeのプログラミング日記
こんな感じになる。ポイントは -H で指定するヘッダーが複数の場合に改行することくらい。 # ab -n 1000 -c 1 -H 'Service-Type:1 Service-User-Id:117504418042902918542 Device-Id:79D0A481-56FD-4FB6-868A-5073F7ECC666 User-Id:120 Version:2.0.0 Os-Type:1' http://xxxxxx.com 実際にどのようなレスポンスを取得しているのかを確認したければ v オプションで確認可能。 v の後ろに 1 ~ 4 の数字を指定するだけ。個人的には想定しているレスポンスかどうかを確認するために最初は -n 1 -c 1 -v 4 で全ての情報を出力している。
yojik 2022/12/06
リンク
DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか（multiple aggregates in one transaction） - pospomeのプログラミング日記
DDDでは集約 = トランザクション境界でなければならないので、複数の集約をまたがるデータの永続化処理は結果整合性になる。なぜ集約をまたいでトランザクションをかけてはいけないのかというと、集約で「データの一貫性の境界」を表現するため。なので、集約同士はデータの一貫性を保証しない = 結果整合性ということになる。集約がトランザクション境界ではない場合はどうなるのかというと、「データの一貫性の境界」がドメインレイヤで表現できなくなる。あるときは集約A, 集約B が一緒のトランザクションで登録され、あるときは集約A, 集約B, 集約C が一緒のトランザクションで登録される、というケースがあると、「データの一貫性の境界」はアプリケーションレイヤのトランザクション開始から終了までのコードで表現されてしまうので、それぞれの集約がどの粒度で一貫性を保たれるのかが分からなくなる
yojik 2016/12/22
ビジネスロジックは、モノとモノの間のコト(=集約ルート間にまたがるオブジェクト)を追加・編集するものが多く(ユーザと組織の間の「所属」とか)、集約をトランザクション境界にするDDD自体の発想に違和感がある。
リンク
1