https://gihyo.jp/magazine/SD/archive/2024/202403
とても良い. リソースレコードっていつ学習してるんだろうね :thinking_face: 実際に設定する機会が少ないだろうしこうやって学べるのは貴重.
とても良い. 学習においては原典をあたるのが重要だと思うけど, エヴァンス本なんかだと時代が違いすぎて鵜呑みすると危ういので, こうやって現代に即した内容で学習すべきなのかもしれない（相対論だって誰もアインシュタインの論文で勉強するわけではないし）. クリーンアーキテクチャなんかもそうだけど, 方法論にばかり注視して本質を見失いがちなので, こうやって丁寧に解説されているのはとても貴重だと思う. 『第1章：ドメイン駆動設計の概要』で概要を理解してその後の2章から4章で具体的な内容になっているので構成もすごくいい.
限られた時間を使って設計を行うのであれば、競争優位を生み出す複雑な業務ロジックに集中するのが、事業活動にとって費用対効果の高い取り組みです。これがドメイン駆動設計の根底にある考え方です。
これ. DDDって現代においては別に難しいことは何も言っていないと思う.
ドメイン駆動設計の基礎となる手法は、戦略的設計ではユビキタス言語、戦術的設計では値オブジェクトです。これらはほかの設計手法の支えるものであり、ドメイン駆動設計に取り組むための土台となります。
ちょっと言い過ぎな気もする. ユビキタス言語はその通りだと思うけど, 値オブジェクトに関しては疑問符. 「副作用のない関数（SIDE-EFFECT-FREE-FUNCTIONS）」として実装すべきということを表明しているのかもしれない. 紙面からは読み取れず.
エンティティが見つかれば、その属性として値オブジェクトのいろいろな候補が発見できます。
とあるので本来のDDDとは別に従属関係があると考えているということなのかもしれない.
具体例があって非常に実用的. さらに要件が追加されたり変更された場合について考えてみるのも面白そう. ユビキタス言語についてはユースケースをきちんと書けるかが重要だと思う. 用語集たしかに大事なんだけど管理が難しい問題はある. 今ならLLM使うのもありかもしれない.
このあたりBDDにつなげられないかなと思う.
ペアプロやモブプロを1人で実施していると考えるとイメージしやすいのではないでしょうか。図を書くときはナビゲーターの役割になって、システムをどのように連携するか大局的な構成を考えることに集中します。コードを書 く際にはドライバーの役割で、ナビゲーターの指示である図に従って、ひたすらコードを書いていくのです。
これ. もう少しベイビーステップにしてテスト駆動開発（というかBDD）と組み合わせてやりたい.
面白い. 特に「Chromiumの機能開発プロセス」はなかなか外からは見えてこないので面白かった.
各サービスの解説がわかりやすくて良い. GKE Autopilotは神.
リリース注1のためには本番環境の踏み台サーバにsshログインし、git checkoutしてからデプロイスクリプトを走らせる必要がある。
あるあるすぎて泣いた.
「プッシュを止めるな！」プロジェクトのマイルストーンでまずは自動化からスタートしているの良き. 「レバレッジが効く自動化から始めよ」とt-wadaさんも言っている.
実録レガシーコード改善 / Working with Legacy Code: the True Record - Speaker Deck
設定値のミスを防ぐためにAWS CDKとTypescriptを組み合わせてるのは面白い.
pros/consがあってけっこう難しい内容かもしれない.
話題のHonoだ. 例がシンプルすぎてピンとこないけどCloudflare Workersを使う目的で 試すのは良さそう.