2017/10/21 開催の関Javaで「DDD失敗談を話して学んだこと」という発表をしました
関西Javaエンジニアの会(関ジャバ) '17 10月度 - connpass
資料中にある通り、この話は 2017/02開催の ScalaMatsuri2017 アンカンファレンスでやったネタです。 このとき色々といい学びがあったのにきちんとまとめていなかったので、DDDをテーマに発表者を募集していると聞いてこのような形で発表をしてみました。 Twitterやはてブで予想以上の反響をいただいて少しびっくりしましたが、それだけみなさん陥りがちな罠なのかなと思いました。
これ実は同じ失敗の仕方をしてるプロジェクトに複数遭遇しているので、こうやって纏めて知見として公開してくれた @aa7th さんには感謝しかない https://t.co/xECYH5LAu5
— がくぞ (@gakuzzzz) 2017年10月27日
こう言っていただけると発表した甲斐があります！
以下、補足です。
雑なアーキテクチャ図
p14とp15の雑なアーキテクチャ図は当日の朝スタバでiPad ProとApplePencilで書いたものです。 増田さんの発表 中に「型のアイデアの発見には雑談やラフスケッチが有効」「きれいな図ではなくラフスケッチを書きながら議論をすべきである」とのお話があり、私が資料中にきれいな図ではなくラフスケッチを出したことをすごく褒めていただけました。
私の図が雑だったのは単に時間がなかったからという理由なので、褒めていただいた時はもうひたすら恐縮していたのですが、雑でもいいからささっと図を書くというのは確かに大事なことだなーと思いました。
アナログツールの活用
パネルディスカッション中に「最初にプロトタイピングツールでワイヤーフレーム(の紙芝居レベル)だけどモックアプリを作った」という話をしたときに「(クライアントと話を詰める手法として)よさそうに思えるのに何が悪かったの？」というご質問をいただき、デジタルツールではなくアナログツールをもっと取り入れた方がよかったと考えていると回答をしました。 私の方でワイヤーフレームを書いてモックアプリとして作って「こんな感じでどうですか？」と動かしながら見せたり触ってもらったりしたのですが、一見よさそうに見えるので「これでいい」という話になってしまいました。すると後々作り込んでいくうちに「やっぱりまずい」みたいな話がごろごろと出て来る羽目に・・・。
ペーパープロトや付箋、ホワイトボードなどのアナログツールを用いて、一緒にモデルや画面の図を書きながら議論をするべきだったと思います。
ScalaMatsuriアンカンファレンスでのメモ
元ネタであるScalaMatsuriアンカンファレンスでの当日のメモは下記のものになります。
余談ですがこの日「UUID」をずっと「SSID」と間違って言っていたことに後で気づいてすごく恥ずかしかったです。(さすがにメモは修正しました・・・)
Play2+DDDを挫折した話
- 要件概要 (若干ぼかしています)
- 作りたいもの
- とある物(例えば部屋)の貸し借りサービス
- AirB◯bっぽい感じ
- とある物(例えば部屋)の貸し借りサービス
- サービス利用の流れ
- とある物(例えば部屋)を貸し出したい人が金額や貸したい物の詳細を登録する
- タイトル
- 写真(複数枚)
- 金額
- オプション料金
- 説明文 etc
- 借りたい人がまず仮予約をいれる
- メッセージをやり取りして、実際の金額と借りる日程を決めてもらう
- 貸す側が予約を確定
- 貸出が終わったら互いに互いをレビューして完了
- とある物(例えば部屋)を貸し出したい人が金額や貸したい物の詳細を登録する
- 補足
- スタートアップ
- クライアントさんはITに詳しくない
- まずは「最低限」の機能でβ版をリリースし、色んな人に意見を聞きながら改善していこうという方針
- いずれは大きいサービスにしていきたい
- 期間は3ヶ月半程度。のつもりだった。
- スタートアップ
- 作りたいもの
- 体制
- 技術
- DDDでやってみようとした理由
- やってみたかった。
- 私のDDD理解レベル
- 仕様とコードの剥離を少なくできるならその方がよいとおもった。
- DDDのプロジェクトのお手伝いをした経験があった
- かくしてPlay2+(なんちゃって)DDDで開発が開始された！
- そしてやめた！！！
- 3週間ぐらいで方針転換した
- 最初の構成
- j5ik2o/spetstore: Scala+DDDのサンプルとしての実装 https://github.com/j5ik2o/spetstore
- ↑参考にさせていただいた
- やめた理由・その1
- 実装コストがたかかった
- やめた理由・その2
- やめた理由・その3
- ScalikeJDBCでcase classや独自型へのマッピングが簡単にできる
- → あれ？もうこれアプリ層から直接呼べばよくね？
- やめた理由・その4
- ユビキタス言語辞典が全然機能しなかった・・・
- サービス内で使用する言葉が全然決まらなかった
- みんなに聞きたいこと
- みなさんならこのアプリをどう作りますか？
- いやDDDでできるだろ etc
- ID設計について
- 今回はうちUUIDを採用した
- DDDをやっている人はみんなどうしているのだろう
- みなさんならこのアプリをどう作りますか？
- みなさんのご意見
- モデリング
- 最初からきれいなモデリングをしようとしたのが悪かったのでは？
- 少しずつ進歩していくものだ
- ちゃんとモデリングしたとき
- モデリングだけで何ヶ月も使っちゃう
- お客さんとモデルをつめるの難しい
- 知識の噛み砕きのフェーズをいれないとダメ
- 1章に書いてるけどみんな覚えてる？
- ドメインに対する知識が深まっていない
- わかったつもりになっている
- 知識を噛み砕かず僕のプロジェクトを真似してもだめ byかとじゅん
- 1人ではできない
- 利害関係者とやらないとだけ
- お客さんがどう理解するか
- 絵にするとか
- とにかく噛み砕く
- アイコニックスプロセス
- 短納期低コストだと仕組みがないときびしい
- 過去に経験があって仕組みがあればできる(かもね)
- DDDじゃなくて単純なCRUDに落とし込んだ方がいい
- モデル探求渦巻き
- モデルの使い方のシナリオ
- モデルを提案してください
- モデルを実装してください
- レビュー
- よい設計・実装を導くには
- 仕様とコードじゃなくて、頭の中とコードを一致させる
- そもそもスケールのことは最初は忘れていいんじゃない？
- モデリング
関Javaのみなさん、この度はよい機会を作っていただいてありがとうございました。