先日参加したのでまとめを書きます。

タイトル: DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方
日時: 2016年5月25日(水) 19：00 - 21:00
会場: 株式会社ドワンゴ　銀座松竹スクエア 13F　セミナールーム
URL: http://ddd-alliance.connpass.com/event/31834/
資料: http://www.slideshare.net/masuda220/ss-62386442

メモ

設計の基本
- アジャイルとオブジェクト指向のつながりはたまたまではない。
  変更容易性を突き詰めていった結果の側面。
- 仕様変更とプログラムの変更が一致しないのはダメなモジュール。
  モジュール性における連続性が低い。
- 機能分割が機能クラス+データクラスなら、オブジェクト指向は抽象データ型。
- メイヤーの本は鈍器。
- 機能分割はモジュール評価における｢わかりやすさ｣や｢連続性｣が低いので変更が大変。
  (メイヤーによると)
- オブジェクト指向なら変更に強いので仕様変更が怖くない。
  むしろお客さんの興味のあったことを理解できたはずなのでムダではない。
見つけ方
- 何気ない用語からドメインの学びは始まっている。
- 利用規約はドメインそのもの。クラスやその振る舞いの要素そのもの。
- アソビューはDDDで開発している。CEOの理解もある。
- とりあえずひな型8点セットや業務の関心事発見パターンを参考にする。
作り方
- getして自分で判断・加工・計算するのはNG。
  これによりロジックの置き場の整理にもつながる。
- nullを渡さない戻さない。全員が守れればチェックはいらない。
  信用できずにチェックをするとなると、それによってコードが汚れるので、
  可能であれば約束事にすべきだ。
- ドメイン層以外は常にシンプルにしておく。
  ドメイン層以外が汚くなったらそれは怪しい箇所としてチェックできる。
- DBや画面はデータをどう扱いたいかだけだからデータをフラットにしたがる。
  オブジェクト指向と相容れないのは仕方が無い。
- ドメインの表現にこだわるためにフレームワークを活用する。
  ドメインが守れるなら、多少の苦労はいとわない。妥協しない。
育て方
- メソッドの抽出を頑張る。
- 2個以上の引数は怪しい。
- 一時変数を値オブジェクトへ。
- 区分オブジェクト。
QA
- コンテキストを超えた範囲での共通化をどうするのか。(名前、電話番号など)
  - コピーがいい。コンテキストごとでドメインが成長するので共通モジュールにしにくい。
- ドメイン層が深いとテストしにくい。
  - 深い階層になるのはドメイン設計に問題がある。
    (増田さんは)ドメイン自体にテストは書かない派。サービスなどはテストを書く。

所感

メイヤー本の話が出た。
昔オブジェクト指向を深く知りたくて読んだけれど、理解できなかったり読み飛ばしたりしたところが多かったのでもう一度トライしてみたい。
いやDDD本の再読の方が先か。
｢オブジェクト指向なら変更に強いので仕様変更が怖くない。
むしろお客さんの興味のあったことを理解できたはずなのでムダではない。」あたりは増田さんらしい。(他ではあまり聞けない)
nullを渡さない戻さないは挑戦しているけれど、チェックしないという発想はなかった。
習慣でLombokの@NonNullつけていたけれど信用できる範囲内ならいらない気がする。
挑戦してみよう。
個人的にオブジェクト指向エクササイズのルール9の考え方(getterを使わない)が
曖昧なことに気がついた。
例えば、商品価格、数量、割引率があって総合価格を計算するときに、どっかにまとめて計算するメソッドを作ってgetしてしまいそう。
そこからのリファクタリングがぱっとは浮かばない。自身の中で整理が必要。
今回は最終補欠が24人いた。次回以降、普通に落選して繰り上がれないことも覚悟が必要。