久しぶりにラーメン食べた以外のことを書きますよ。
java-ja.dddなる勉強会的なイベント(勉強会と銘打つのは嫌いらしいので「的」ということで)に。
参考資料：java-jaとはなんでしょうか？教えてください。
DDD(ドメイン駆動設計)
おまけ：
おまけ２：みんなDDD!って騒がしいのはどういうこと？
前提知識はこんなもんでいいかな。
さて、イベントの様子は当時のツイートが抽出されたtogetterを参考にしていただくとして(僕もツイートしてるよ～)、個人的にアンテナにかかった、メモしておきたいところや感想を徒然にメモ。
- java-jaこわくないヨ。
- グリーさん会場ありがとう。きれいで広い、いい会場ですね(ヒルズ森タワーのビジネスエリアに入ったの何気にはじめて)。
- 大事なのは、エンジニアが業務知識を理解すること、業務知識に基づいた製品を作っていることを自覚すること。
- そのために業務知識のコードをシステム内部のためのコード(ファイルとかDBとかネットワークとか…)を分離すること。業務の文脈を業務の言葉で記述すること。
- とはいえ、作るシステムの複雑(単純)さにあわせないとFizzBuzz EnterpriseEditionになってしまう。これは複雑な業務知識を取り扱うときの話。
- モデルとは適切に単純化されたものである。
- ドメインエキスパートは正解を教えてくれる存在ではなく、一緒にシステムを作り上げる仲間。いないなら自分で兼任するしかないが、その役割に自覚的な方がいいだろう。
- 境界コンテキスト大事かも。使っている言葉が届く範囲を意識するのは設計として重要。
- コンウェイの法則知らなかった。でもわかるわー
- DDD本の参考文献に出ている本をどれだけ読んでいるかでDDDの初期の理解が全然違うようだ。GoFのデザインパターン
、リファクタリング
、アナリシスパターン
、テスト駆動開発入門
、オブジェクト指向入門 第2版 原則・コンセプト
…(結構読めてない)
- ドメイン領域のコードに使う名前を業務の言葉で埋め尽くす。とても大事。
- ドメイン層において「汎用は悪」って話は目から鱗。ドメイン層にドメインをきちんと分離できれば当然そうなるよなー。業務が違えば中身が違ってくるのが当然だし。共通化、効率化、汎用化はインフラストラクチャ層で。
- 同様に、ドメイン層に例外は要らないって話も、エラーは当然想定する(例外じゃなく処理する)べきだし、インフラストラクチャ層で起きた例外はインフラストラクチャの中で解決して、ドメインには「ごめん失敗したー」って返すべきだよなあ。
- SQLアンチパターン
買わなくちゃ
- RailsのActiveRecord便利だけどDBと密結合すぎてヤバい。
こんな感じかな。
凄く濁った心が洗われるようなイベントでした。8割がた、当たり前のことをちゃんとやれば実現できる話なのですが、ちゃんとやりやすくする手法とか、貫くための心構えとか、そういうことがまずあるんですよねDDDって。頑張り続けないとなー
あと、大規模開発はコミュニケーションと共有大事よねって改めて思いました。独りよがり危険。
最後に
GREEさん会場ありがとう！
java-ja楽しいよ。こわくないよ！次回も仕事の具合次第だけど行きたいー
追記
java-ja.ddd の資料、ブログ記事などのまとめ
