本記事は、DDD-Community-Jp Advent Calendar 2020の16日目です。
はじめに
DDD-Community-JP(以下、DDDCJ)内で開催するモデリング会が始まって、1年になりました。
コード面、チーム面など、いろいろな角度の学びがあったので一度カテゴリ横断でざっくり見直してみます。
モデリング会のこれまで
ざっくりとタイムラインで書きました。
- 黄色は、大体やってる内容.
- 😼は、モデリング会開催日。
- オレンジ色は、自分の過去twitterからピックアップした気づきです。
話のカテゴリ
以下の話題に分けて、話をしていきます。
全部は書ききれないので、ピックアップしていきます。
- モデリングに関する学び/気づき
- DDDに関する学び/気づき
- コードを書く上での進め方
- チーム体制
モデリングに関する学び/気づき
EventStorming + RDRA は強力!
最初はユースケースから単語を切り出してドメインモデルを作る、ぐらいにやってました。
ただ、これだとコーディングを進めていくうちに集約の切り方が怪しいことがわかり、
さらにはドメインイベントの定義が怪しいこと、
もう一歩行くと要件がちゃんと捉えられていないことが見えてきて。
こんな悩みに、EventStorming + RDRAは強力です。
詳しくは以下の記事を。
ツールの力は偉大
途中から miro を使い始めましたが、
この無限に広がるホワイトボードは強力。
書いたモデルの数々は、以下の記事をご参照ください。
モデルに書くのは、必ずしも実態じゃない。
不要なものを書くべきか？と思いつつ、
他と違うことがわかる「黒」付箋で不要にしたものの理由を書いてみました。
Modelに、前回「予約ステータスはいらない」という話をして、モデルに不要理由を残しておいた。
— 98lerr (@98lerr) November 22, 2020
2週間経ったのち、理由がすぐにキャッチアップできた。消した理由って残らないこと多いけれど、残しておくのは大事。
(いつも、消した要素やコードごとWhyのコメントも消してしまう...)
#ModelingKai pic.twitter.com/dQk3FLM5r0
これが、効果あり。
議論したところって印象に残るものの、
議論が白熱しすぎると最終的結論の背景が思い出せなくなったりする。
(議論の枝葉が残ってたり。結論の背景は議論疲れした頃の話なので)
あまりに多すぎるのはノイズだけれども、
議論が盛り上がる部分の「不要な理由」は大事です。
DDDに関する学び/気づき
構造の流派/思想がいろいろ出てくる
ここは、Advent Calendar に言及した記事が複数あるのでそちらへのリンクを。
各レイヤーの責務の捉え方で、パターンはいろいろ出てきます。
- リポジトリインターフェースはどこに置く？
- 入力はどこで値オブジェクトにする？
コード、どこから書く？
ここは、諸説分かれるかなと今も思います。
個人的には、以下の見解。
- まず、雑なコードでもユースケース側を作る。
- そこから、ドメイン層を作る。
モデルを反映する先としてドメイン層を作って行きたくなるところなんですが、
結構「あれ、このドメイン層組み立てだとユースケース層から使えなくない？」みたいなのが出てきました。
ユースケース側があると、
視座を上下に移動しながらコードを書く助けになるな、という印象です。
InMemory リポジトリの危険性
よくある話、InMemoryでのリポジトリの実装。
途中SQLiteに置き換えてみると、実際の永続化できるDBと勝手が全然違う気づきが。
手元で出来るなら、出来る限り本物を使ってテストをすべきなんだと、身を持って体感した。。。#ModelingKai
— なかじま (@jnuank_) May 19, 2020
インメモリでのテストと、ホンモノのテストの役割はぜんぜん違うぞ！ ひー！#ModelingKai
— おーひら (@mohirara) May 19, 2020
インフラを抽象化しないでベタで変数に入れて実装していたところ。
SQLiteはローカルテストにも簡単に使えて便利ですね。(あとで型の制約に苦しみましたが)
コードを書く上での進め方
トップメソッドのレベルを揃える！
今回は、リポジトリの実装を抽象度レベルが揃うように整理する回だった。リポジトリのトップメソッドにはwhat (処理の流れの概観が分かるレベルの記述) を、そのhow (というか、クエリ文やクエリパラメータへの変換といったの詳細) を別に括り出すことで、コードがすっきりした。#ModelingKai
— Siena. (@n_siena) July 5, 2020
コードをごりごりかく前に、トップレベルはまず箇条書きで書く。
書き始めてしまうと、俯瞰してみるのが難しくなることありますね。
TODOとしてすっきりした形から書き始めると、よくわかるという学びでした。
いろいろ試すけど、出来上がりはいつ？
Dapper やった頃に出てきた指摘です。
リポジトリ層をどんどんリファクタしてくのに白熱していったのですが、
そこで入った指摘。
「で、要件満たしたもの動くの？」
半年経って、まだ実装していない要件たくさん残ってる現実。
実際の現場でこうなってしまっては大変！
どうしよう、という話でなく、
これも「学びがたくさんあったからOK!」と言える勉強会形式がいい！というところ。
チーム体制
チームの掟！
モデリング会を始めて間もない頃に、以下の掟ができました。
-
チームの掟
- 論よりコード
- 無責任デリゲーション
- ワールドメーカー【俺がルールだ】
- まずは負けてみる（ゴン・フリークス@天空闘技場）
特にオンラインの場だと、あれやこれやと空中戦起きやすくなります。
言葉にするより、疑似コードで比べられるようにする。
最後はドライバー（あるいはドライバーが指名した人）が独断で決める。
多数決は要らない。
失敗したっていい。
結構、現場であるあるな悩みを解消するのにも有効なルールじゃないかと思います。
初回のオフラインも、学び多かった。
初回の話は、以下にあります。
個人的には、「ふりかえり ≒ 反省会」のイメージを持っていたので、
ここでやった FDL はかなり衝撃的でした。
Mobプロのためのレイアウトも、オフラインでやる上で強力でした。
(残念ながら、covid-19 で以降ほとんどオフラインMobの機会なくなりましたが)
タイムボックス
いろいろな手法をどんどん取り込んでいくし、
コードの書き方も新しいことに取り組んでいくモデリング会。
楽しいんですが、楽しいだけに議論白熱すると時間がどんどんすぎていってしまうんですね。
タイムボックスを意識。
30分後に、どういう話になっているか考えて進める。
30分経ったら、どうなったか一度話す。
一度冷静になる機会を設けることで、話がどんどん脱線してあらぬ方向へ…というのは避けられますね。
議論の白熱具合では話を必ずしも切るわけではないし、
この30分区切りが常にできてるわけでもないですが。
意識としては、大事。意識するだけで、進み方は変わりますね。
まとめ
改めて書いてみて、モデリングに依存せず広い学びがあったのだというのを認識できました。
タイムラインのイベントベースで書いたためここにはないですが、オンラインモブプロ体制自体の知見も集まってると思います。
もう一つ。
ざっと振り返ることができたのも、Twitterに毎回学びを呟いてたお陰と思います。
最初の頃は「終わったら一人3ツイートルール」とかやっていましたが、その効果と言えます。
プチアウトプットは大事ですね。