読者です 読者をやめる 読者になる 読者になる

ほげほげ(仮)

仮死状態

java-ja.dddに参加して来ました

3/22に行なわれたjava-ja.dddのメモです。

※かなり殴り書きの個人的なメモです。

第一部 ざっくり DDD 入門!!

  • システムを複雑にしているのはドメイン
  • 業務知識とはデータの構造、演算、他システム連携
  • 業務知識を知るのは結構あと。結合テストとかで分かることがある
  • 業務知識を反映されることでソフトウェアは柔軟に変更、拡張できる
  • トランザクションスクリプトに重要なロジックが隠れる
  • モデルの中で制約を表現する
  • 複雑なドメインの設計はモデルを元に設計
  • モデルとは専門家によって整理され単純化された世界観
  • ドメインに詳しい人と話してモデルを共有する
  • ドメインエキスパート:業務を回している人、データ裏側もわかってる人。
  • ドメインエキスパートの人を探すのが大変
  • whirlpool
    • http://domainlanguage.com/ddd/whirlpool/
    • シナリオ→モデル→シナリオを繰り返して、コードを書いていく
    • Code Probe: コードを使ってモデルの中を探索する
    • ソフトウェアにモデルを反映させていく
  • モデルとは?
    • 業務のモデル。シンプルに考えるとER図(データベースだけではなくオブジェクトの世界。データベースと言い切ってしまうと、データベース+アルファが表現されない)。
  • ドメインが散らばってる場合
    • 基準:ある言葉が同じ意味を持つのまでが同じドメイン。部署の境界がドメインの境界。
  • ブルーオーシャン(スタートアップ)を目指す人にとっては議論の結果を残して反映していく
  • MVC: Viewを通じてモデルをコントロールする

第二部 ガッツリ DDD 実践編!!

  • ドメインエキスパートはいない!(バッサリ言い切った)
  • ドメインエキスパートは複数形
  • 前提の本を読む必要がある。
  • リッチなトランザクションスクリプトとシンプルなドメインモデル(getter、setter) → 型にテーブルの型。型安全。 → シンプルなトランザクションとリッチなドメインモデル
  • ドメインモデルは業務の言葉で組み立てる。小さなオブジェクト。
  • ドメインモデルの開発
  • 名前に対する違和感が解消されればドメインとして分かる
  • 各名前(クラス、メソッド)を業務の言葉で埋め尽くす
  • スタートアップはドメインエキスパートになろうとしてる
  • 名前はすべて英語でつける
  • Javaの型を使うんじゃなくてすべてラッピングしてドメインのオブジェクトを作る
  • ファンダメンタルなオブジェクトを育てたり整備するのが仕事を楽にする
  • トランザクションスクリプトにコード書きすぎるのではなく委譲オブジェクトに任せる
  • トランザクションスクリプトが扱うのはEvent、Repository、Transfer、Reference
  • 業務で共通してないものはロジックで共通化してはいけない(変更に弱くなる)
  • 良い名前。小さく作る。ばらばらに。
  • 良い名前の見つけ方
    • 語彙を増やす。読む/調べる/聴く/尋ねる
    • 名前の宝庫
      • その分野のガイドブック
      • 類似サービスのヘルプ画面
      • 類似パッケージのカタログ(英語版ならクラス名の宝庫)
    • 正しく使う
      • 難しい
      • 言葉は使えるけど、なんか使い方が違うことがある。そういうのに気づいていく
  • 小さく作る
    • クラス 50行
    • メソッド 3行以内
    • パッケージ 10ファイル以内
    • これを超えたら分割を考える
  • ドメインモデルでtry catchはおかしい
  • HowよりWhat
    • 業務の言葉をメソッド名をリンクさせていく

 expireData.add(-1);
  ↓
 expireDate.previousDay();
  ↓
 expireData.dayOfFinalAlert();

  • 汎用部品を専用部品に
    • 型をすべてラッピング
    • Listは複数形クラス名でラッピング
    • 再利用を目指すものではない
  • ifを使わない
    • enum
    • strategy / state パターン
    • Missing Objectパターン(null object)
    • Map, Set
    • BeanValidator 入力チェック
    • Assert nullはないという前提、制約をつくる。
  • forを使わない
    • ファーストクラスコレクション
    • コレクション操作ロジックの置き場所

   new Appints(List);

    • Collection フレームワークAPIの復讐
      • TreeMap、LinkedHashSet、Deque(デック)
      • Comparable、Comparator
  • setterを使わない
    • 完全コンストラクタ
    • ValueObjectパターン

   new Money(amount, currency)

    • setXXXで状態を変えない
  • getterを使わない
    • @Deprecated を使う
      • フレームワークから使う時はいいけど、アプリケーションでは使っちゃいけない
    • getしたいときは、役割分担がおかしい
  • 構造の変更に備える習慣
    • 構造は安易にコードに埋め込まない
    • 初期の構造はまちがっていることが多い
  • パッケージスコープを好む
    • public宣言ををもっと控えめに
    • パッケージスコープにできないか
  • import文を少なくする
    • パッケージスコープにすればするほどimport文が少なくなる

第三部 俺にもちょっと DDD 喋らせろ!!

すいません、メモってなかったです…

感想

java-jaには初参加でどんな空気かが心配だったのですが、心配したとおり今まで参加してきたもので一番特殊でした。
発表の途中で後ろから「カシュッ」「カシュッ」ビールを開ける音するし…
発表中もボコボコと質問が飛び交ってるのもすごいと思いました。

yoshioriさんが「java-ja怖いって書くのやめてねー」言ってましたが、怖いというよりみんな無邪気に楽しんでる印象でした。

ビールとピザはGREEさんから無料で提供。ありがとうございました。
ピザ食えなかったですが…

発表内容はすごく聴き応えのある内容でかなり勉強になりました。
増田さんのお話は去年のDevLOVEカンファレンスで少し聞いたのですが、その時はまだ全然イメージができていなかったのですが、少しはイメージできるようになった気がします。

DDD本は持ってはいるのですが、まだ読めてないです><
今は実装パターンを読んでいる途中です(実は1回読んでるけど中身が頭から抜け落ちてるでやり直しです)

今は実装するなかで出来るだけ小さな単位にメソッドを分けたりしているのですが、まだドメインを意識できていないと思っています。DDDはぼんやりとしかイメージできていないので、早めにDDD本を読みたいと思います。

色々おもしろい話が聴けて楽しかったです。ありがとうございました。