『現場で役立つシステム設計の原則』を読んだ

memo

  • DDDではDB設計はどのタイミングで行うのだろうか
    • 全く別軸でDB設計が進むならば何のためにドメインを洗い出すのか分からない
    • 並行して行う感じか
  • アプリケーションコード、DB設計などあらゆる局面において名付けは大切。守るべきポイントは共通している(省略しない、業務の言葉を使うなど)。
    • リーダブルコード
  • DB設計
    • 基本はコトの記録
    • 参照時の性能を考慮して現在の状態を表すテーブルも用意する
      • 懸念点
        • 書き込み、更新処理が増える
        • 複数テーブル間の整合性をDB制約で担保できない
          • アプリケーションコードでするにしてもしんどい感じになりそう

感想

  • 通読は2回目だったが、実践できていないプラクティスがあったので心に刻んでおきたい
  • ドメインの整理方法、DBの論理設計とだいぶ似通っている
  • DDDを使ってフレームワークに依存しない設計にすればRailsだろうがSinatraだろうがHanamiだろうが容易に交換可能なアプリケーションにできるんだろうか。
  • Web APIのデータ交換において、JSONだと困るけどXMLなら困らない場合のイメージがつかない