関Javaで「DDD失敗談を話して学んだこと」という発表をしました

2017/10/29   #IT勉強会  #DDD 

2017/10/21 開催の関Javaで「DDD失敗談を話して学んだこと」という発表をしました

関西Javaエンジニアの会(関ジャバ) ‘17 10月度 - connpass

資料中にある通り、この話は 2017/02開催の ScalaMatsuri2017 アンカンファレンスでやったネタです。 このとき色々といい学びがあったのにきちんとまとめていなかったので、DDDをテーマに発表者を募集していると聞いてこのような形で発表をしてみました。 Twitterやはてブで予想以上の反響をいただいて少しびっくりしましたが、それだけみなさん陥りがちな罠なのかなと思いました。

こう言っていただけると発表した甲斐があります!

以下、補足です。

雑なアーキテクチャ図

p14とp15の雑なアーキテクチャ図は当日の朝スタバでiPad ProとApplePencilで書いたものです。 増田さんの発表 中に「型のアイデアの発見には雑談やラフスケッチが有効」「きれいな図ではなくラフスケッチを書きながら議論をすべきである」とのお話があり、私が資料中にきれいな図ではなくラフスケッチを出したことをすごく褒めていただけました。

私の図が雑だったのは単に時間がなかったからという理由なので、褒めていただいた時はもうひたすら恐縮していたのですが、雑でもいいからささっと図を書くというのは確かに大事なことだなーと思いました。

アナログツールの活用

パネルディスカッション中に「最初にプロトタイピングツールでワイヤーフレーム(の紙芝居レベル)だけどモックアプリを作った」という話をしたときに「(クライアントと話を詰める手法として)よさそうに思えるのに何が悪かったの?」というご質問をいただき、デジタルツールではなくアナログツールをもっと取り入れた方がよかったと考えていると回答をしました。 私の方でワイヤーフレームを書いてモックアプリとして作って「こんな感じでどうですか?」と動かしながら見せたり触ってもらったりしたのですが、一見よさそうに見えるので「これでいい」という話になってしまいました。すると後々作り込んでいくうちに「やっぱりまずい」みたいな話がごろごろと出て来る羽目に・・・。

ペーパープロトや付箋、ホワイトボードなどのアナログツールを用いて、一緒にモデルや画面の図を書きながら議論をするべきだったと思います。

ScalaMatsuriアンカンファレンスでのメモ

元ネタであるScalaMatsuriアンカンファレンスでの当日のメモは下記のものになります。

余談ですがこの日「UUID」をずっと「SSID」と間違って言っていたことに後で気づいてすごく恥ずかしかったです。(さすがにメモは修正しました・・・)


Play2+DDDを挫折した話

  • 要件概要 (若干ぼかしています)
    • 作りたいもの
    • とある物(例えば部屋)の貸し借りサービス
      • AirB◯bっぽい感じ
    • サービス利用の流れ
    • とある物(例えば部屋)を貸し出したい人が金額や貸したい物の詳細を登録する
      • タイトル
      • 写真(複数枚)
      • 金額
      • オプション料金
      • 説明文 etc
    • 借りたい人がまず仮予約をいれる
    • メッセージをやり取りして、実際の金額と借りる日程を決めてもらう
    • 貸す側が予約を確定
    • 貸出が終わったら互いに互いをレビューして完了
    • 補足
    • スタートアップ
      • クライアントさんはITに詳しくない
    • まずは「最低限」の機能でβ版をリリースし、色んな人に意見を聞きながら改善していこうという方針
    • いずれは大きいサービスにしていきたい
    • 期間は3ヶ月半程度。のつもりだった。
  • 体制
    • WebでもiOSでもAndroidでも利用できるようにしたいとのことだったので、レスポンシブWebアプリとして作成することに。
    • 仲のよいシステム会社さんにサポートをお願いした。
    • インフラ・運用・コードレビュー etc
    • ScalaコードレビューをTech to Valueさんに依頼
    • プロジェクト初期から中盤までレビューしていただいた
  • 技術
    • Play2.5/Scala
    • ScalikeJDBC + SkinnyORM
    • 使ったことはなかったけど、周囲の評判から判断
    • MySQL5.7
    • サポート役のシステム会社さんと相談して決定
    • 後日都合により5.5にダウングレード
    • さくらのクラウド
    • 最初はなるべくランニングコストを抑えたいため
  • DDDでやってみようとした理由
    • やってみたかった。
    • 私のDDD理解レベル
    • https://speakerdeck.com/sammy7th/dddtutenandarou
    • 仕様とコードの剥離を少なくできるならその方がよいとおもった。
    • DDDのプロジェクトのお手伝いをした経験があった
  • かくしてPlay2+(なんちゃって)DDDで開発が開始された!
  • そしてやめた!!!
    • 3週間ぐらいで方針転換した
  • 最初の構成
  • やめた理由・その1
    • 実装コストがたかかった
  • やめた理由・その2
    • 「MySQL(RDB)なのによさがいかせてないじゃん」というツッコミがはいった
  • やめた理由・その3
    • ScalikeJDBCでcase classや独自型へのマッピングが簡単にできる
    • → あれ?もうこれアプリ層から直接呼べばよくね?
  • やめた理由・その4
    • ユビキタス言語辞典が全然機能しなかった・・・
    • サービス内で使用する言葉が全然決まらなかった
  • みんなに聞きたいこと
    • みなさんならこのアプリをどう作りますか?
    • いやDDDでできるだろ etc
    • ID設計について
    • 今回はうちUUIDを採用した
    • DDDをやっている人はみんなどうしているのだろう
  • みなさんのご意見
    • モデリング
    • 最初からきれいなモデリングをしようとしたのが悪かったのでは?
    • 少しずつ進歩していくものだ
    • ちゃんとモデリングしたとき
      • モデリングだけで何ヶ月も使っちゃう
      • お客さんとモデルをつめるの難しい
    • 知識の噛み砕きのフェーズをいれないとダメ
      • 1章に書いてるけどみんな覚えてる?
      • ドメインに対する知識が深まっていない
      • わかったつもりになっている
      • 知識を噛み砕かず僕のプロジェクトを真似してもだめ byかとじゅん
      • 1人ではできない
      • 利害関係者とやらないとだけ
    • お客さんがどう理解するか
      • 絵にするとか
      • とにかく噛み砕く
    • アイコニックスプロセス
      • ドメイン駆動をやるためのプロセス
      • ドメインモデルをラフで作る
      • ユビキタス言語の候補をつくる
      • シナリオを出す
      • 最初に作ったドメインモデルにはない言葉がでたりする
      • ドメインモデル図とユースケースモデル図を出して
      • ユースケースモデルのシナリオもだす
      • ↑開発リスクが高いところだけ
      • 実装に関する設定
      • ロバストネス分析
      • 分析を設計におとす前段階
      • 最初のドメイン図とユースケースモデル図があってるかのレビューのときにこの
      • コスト高いしバランス難しい
      • クライアントさんもシステムをわかってくる
    • 短納期低コストだと仕組みがないときびしい
      • 過去に経験があって仕組みがあればできる(かもね)
    • DDDじゃなくて単純なCRUDに落とし込んだ方がいい
    • モデル探求渦巻き
      • モデルの使い方のシナリオ
      • モデルを提案してください
      • モデルを実装してください
      • レビュー
    • よい設計・実装を導くには
    • 仕様とコードじゃなくて、頭の中とコードを一致させる
    • そもそもスケールのことは最初は忘れていいんじゃない? —

関Javaのみなさん、この度はよい機会を作っていただいてありがとうございました。