第4回 Data-Oriented Programming 読書会

development javaeestudy

参加者トピック

ディスカッション

6.3 Unit tests for queries

文字列で比較するのをやめて、デシリアライズしたデータを比較する

6.4 Unit tests for mutations

ラッパー関数が多いときは末端の関数からテストを作る

Chapter 6. Moving Forward (ストーリーパート)

  • テオは開発がスケールしないという理由でDOPを採用しないつもりになっている
  • ジョーはそれを引き留めるため、オフィスで会話することにした

Part 2. Scalability (ストーリーパート)

  • DOPで作り直したプロトタイプには課題がある
    • 汎用的なデータ構造のため、開発者が増えると困ってしまう
    • 同時実行制御はスレッド安全ではない
    • structural sharingの仕組みはデータが複雑になると性能が悪くなる
  • どの課題もDOPを採用する妨げにはならない
  • DOPの理解を深めるために次のレッスンを始めよう

7.1 Data validation in DOP

  • データ表現とデータスキーマを分離する
  • システム境界を越えるデータの検証
    • システム内部で予期せぬデータが生まれてしまう可能性が減る
  • システム内部のデータの検証
    • コードベースが大きくなってもコーディングが容易になる

7.2 JSON Schema in a nutshell

JSONスキーマ

7.3 Schema flexibility and strictness

(感想)データ表現とデータスキーマを分けるという考え方は、同期や共有、後方互換性を保証するためのコストがかかるので、メリットよりデメリットが上回りそう

ロバストネス原則 - Wikipedia

7.4 Schema composition

anyOf や allOf は便利そう

7.5 Details about data validation failures

Ajv JSON schema validator

7. Summary

  • システム境界でデータを検証し、境界の内側におかしなデータが入ってこないようにする
  • 開発環境ではシステム協会の内側でもデータを検証する
    • 名前の間違いを見つけたりできるので、開発の役に立つ

8 Advanced concurrency control

  • アトム というロックフリーな仕組みで並行処理を制御する
    • デッドロックを回避するために必要なロックの通常の複雑さは、アトムには適用されない

8.1 The complexity of locks

  • 不変データなら、読み取り中に他のスレッドが書き込みしても、一貫性は保たれる

8.2 Thread-safe counter with atoms

  • mutex を隠しているだけで特にいいことはなさそう
    • 解放忘れを避けられるし、CAS操作はCPUレベルの命令なので安心

8.3 Thread-safe cache with atoms

突然インメモリーキャッシュの話題になっていてよく分からない

8.4 State management with atoms

  • メッセージキューで操作を直列化するやり方に対するメリットは?
    • 扱うデータが複雑でも性能が劣化しないように思われる

8. Summary

参考情報