【第2回】ドメイン駆動設計のための オブジェクト指向プログラミングに参加しての個人的メモ

【第2回】ドメイン駆動設計のための オブジェクト指向プログラミングに参加して

超個人メモだけど、良い経験になったのでブログにメモを残します。

見てる人いるかわかりませんが、ユーザ定義型の数が多かったと発表したのは私です。 15-6かな?って言いましたが、19個ありました。 今日のテーマに沿ってやったつもりだったんですが、みんな全然着眼点が違かった…。 とても勉強になりました。

序章

  • モデルとは、人間が頭のなかに理解しているものをさす

    • それを言葉や図などで表すのと同じように、コードでも表現すると言う発想をする
  • モデルをコードで表現する、というのは今日のキーワード

    • 型!
  • 問題領域の例として、アソビューのサービスを取り上げる

    • それをどうやってモデル化するかについて取り組んでみる
  • UMLが厳密なものという意識を持っている人がいるかもしれない

    • DDDの文脈ではUMLはラフスケッチ用
    • コミュニケーションに使いやすいから使っているだけ

キーワード

  • 型をプリミティブ型でどうやって表現しているのか

    • StringやLocalDateなどの標準クラスを見るととても勉強になるよ
  • BigDecimalは型の教科書としては良くないよ

  • 独自の方を定義する仕組み

    • class
    • interface
    • enum
    • (package)は厳密には型ではないけどそれを取りまとめる役目に使える

アンチパターン

  • 基本データ型への執着
    • これをやると、メソッドが長くなったり引数が増えたりクラスが巨大化したりする
      • これが他の不吉な臭いに伝搬する根本原因(か?)
    • 逆にユーザ定義型に執着するほど、オブジェクト指向の旨味が出てくるとも言える
  • 処方箋

    • 値オブジェクト
    • コレクションオブジェクト
    • 区分オブジェクト
  • 執筆した本では局所化すると言ってるが...

    • 実際には変更の分散は起きる
      • しかし、推測可能だったりツールが変更の影響箇所を教えてくれたりとか、変更の難易度は下がる

型について

  • 基本データ型をラップするとは?

  • ユーザ定義型がいい理由

    • 正しい
    • 表現力
    • Find Usage
  • 正しさ

    • 基本データ型

      • 汎用的
      • 値の範囲
      • 可能な操作
      • 特定の目的のためには、間違った範囲、間違った操作を含んでいる
    • ユーザ定義型

      • 値の範囲を用意に合わせて制限
      • 可能な操作を用途に合わせて限定
      • 間違いが減る
      • 安心・安全
  • 表現力

    • 基本データ型
      • いろいろな用途に同じ型を使う
      • 意図が不明
      • 10個とか多い単語で説明されてもわからない
    • 意図が伝わらない

    • ユーザ定義型

      • 用途が明確になる
      • 引数の型、メソッドの型、シンプルのメソッド名
      • 型をレビューすればコード内容が推測できる
    • ドキュメント性がある
    • 引数と返りの型をユーザ定義にすると、意図がわかりやすくなる
    • 増田流レビュー

      • else文がある場所やネストが深い箇所を探してピンポイントにレビューする
      • ユーザ定義型を使ったコードだとメソッドまでみれば、その人が業務をわかっているかどうか判断できる
        • 怪しいのはなんでこの型が入ってるの?何が正解なの?という感じで業務を取り違えている可能性があるので警戒する
    • Find Usage

  • ドメインに特化したユーザ定義型

  • ユビキタス言語などから型を探す
  • 汎用の型を用途限定にラップして型にする
  • 既存アイデアの流用/カスタマイズ
    • 即効性はないが、知識を積み重ねておくと後から効いてくるかも?
  • 型の振る舞いの設計パターン
    • 判定(同地、大小、最大/最小)
    • 加工(型変換、短縮形、合成)
    • 計算(四則演算)
  • 他のところから考えた型を別の指標で検算してみることもある

勉強会で与えられた課題

  • スライドの表を実装するにあたり必要となりそうな独自の型を定義してモデルと実装を一致させる(ために思考してみる)
    • コードで書けるときにはコードでいきなり書いちゃえ、コードでかけないときは図などに頼る
    • 英語が思いつかないなら、日本語でもいいかもね

エピローグ

  • たとえ1行だとしても、ロジックが出て来たらオブジェクトに抽出しておくと吉。

    • どんなコードでも正しく動いてしまうと後から書き換えるのは心理的に辛い
  • 現場に導入しづらい?

    • 前段階として、リファクタリング
      • 大きなクラスを分割してみるアプローチがいいと思うよ
  • テスト駆動開発でいってた良いこと
    • 『やりすぎて見てからちょうど良いところが分かるよ』
      • どのへんで折り合いつけるのかわかってくるので、一度やりすぎてみるとよい

以上!あー、楽しかった。