[podcasts.google.com](https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy8zMzBhOTQ4OC9wb2RjYXN0L3Jzcw/episode/MmE0OTNjMTAtZGUxMS00OTdkLWIzNjctMWE2MzA4ODUyY2Ey?sa=X&ved=0CAUQkfYCahcKEwjgqJ7A_KvvAhUAAAAAHQAAAAAQAg)

メモ（きになったところだけ）

• composed_of だと freeze される
• immutable なオブジェクトのデメリットはメモリ消費が多いこと
  • これは処理系レベルで解決されるべき問題
• コンテナ数をスケールアウトすることが容易になってきたので、1 コンテナの中でのプロセス数を増やすことは（少なくとも一般的な web アプリケーションでは）目指さなくてよいのでは
• （契約による設計において）assertion error と exception は異なる
  • assertion error は、ありえないこと、以下のときに投げる
    • 仲間内の利用者が約束を守っていなかったとき
  • exception は、呼び出し側が約束を守っていたとしても発生するかもしれないこと
    • 外部（API とか）の利用者が約束を守っていなかったとき
    • 利用者は約束を守っているけど問題が発生したとき
• assertion はそんなにいっぱい書かなくていいんじゃないの、という話
  • お互いに全てを疑ってガード節を並べるのではなく、約束を設けて、呼び出し側のことを信頼する
  • コントローラで不適切な入力はちゃんと弾いて、適切な引数で呼んでくれているのだろうから、モデルではいちいちガード節は書かない、と。
  • そうすると全体最適になる
• VO はコンストラクタで validation を書く
  • そもそも invalid なオブジェクトは存在しえないようにする
  • これは invalid なオブジェクトが存在しうる Rails のモデルとは大きく異なる
• なぜ Rails では invalid なオブジェクトの存在を許しているのか
  • Rails では、ユーザーからの入力をいったん受け入れるのをモデルでやっちゃうから
  • モデルより外側に validation をする場所があるなら、モデルは valid なものしか存在しえない世界にできる
  • Rails はその雑さと引き換えにレイヤーの少なさ=単純性を実現している
  • モデルに書くことによって、外部/内部からの入力に対する validation を一箇所に書けるようになっている

おもったこと

VO は immutable な方がいいよね、というだけで、mutable でもありうるよな

Ruby は。

str1 = “foo” str1.object_id # => 180 str2 = “foo” str2.object_id # => 200

VOである

str1 == str2 # => true

mutableである

str1.concat(“bar”) # => “foobar” str1 # => “foobar” str1.object_id # => 180

しかし mutable にすることのメリットがいまいちわからん。 メモリ消費の抑制というのはそこまでの理由ではない気がする。 なぜ mutable にしたのだろうか？