まさかの参加したハンズオンがこのモデリング本出してたBIGLOBEさん主催で、願望が叶ってしまった。。笑
もっとやりたくなったので私の住んでるシェアハウスで、自己満モデリング会を定期的に主催することにしました！詳細は別途connpass載せます！#genbadeDDD https://t.co/feIPUUispU
— nari@エンタメ系エンジニア (@fukubaka0825) 2019年5月11日

上記のツイートのように、BIGLOBEさんの本を技術書店で買い、たまたまその後参加したモデリングハンズオンがBIGLOBEさん主催で、定期的にモデリング会やりたい欲が止まらなくなったためです笑

また、今後はDDDやマイクロサービアーキテクチャなど広範な設計の勉強をしていきたかったため、このような名前で発足しました。

2.自分の住んでいるシェアハウスが活発にイベント開いていく流れを作りたかった（外向けにも)

私はギークハウス新宿というエンジニアが共同生活するシェアハウスに住みはじめたのですが、思った以上に勉強会や知の共有がされていない、、

せっかくギークハウス住んでいるんだから、各々が刺激しあいアウトプットしていく集団にしていきたいなという話を、同じく住人の wami さんと話していて、その契機になればいいなと思ったのも一因です。 (アウトプットするところに知識は集まっていくと思っています。)

当日のイベントの概要

テーマは「会議室予約」
言語はGolang
4(5)人一つのチームで別れる（A,B)

私が以下のようなUsecaseドキュメントの準備まで済ませ、そこから名詞や動詞を抜き出して、ドメインモデルを作っていく流れにしてみました。

# 会議室予約api仕様
## 会議室(マスター)
スサノオ
アマテラス
ツクヨミ
## 予約単位
１h(ex. 1400~1600)
## 予約可能時間
900~1800
## UseCase
- 会議室と時間を指定して、会議室を予約できる。
- 予約に成功すると、予約の詳細が帰ってくる
- 時間可能範囲外の時間帯に予約がくると、エラーを返す
- すでにその時間帯に予約があって予約ができなかった場合、すでに入っていた予約のリストを返す
## test前提
- 5/27 スサノオ 1200-1300,5/27 アマテラス 1300-1500,ツクヨミ 1200-1300と1400-1600の予約が入っている
- 上記の4件だけ入ってる想定で
## testケース
- 5/27 スサノオ　1300-1400の予約は成功し、その予約の詳細を返す
- 5/27 アマテラス 700-800の予約は失敗し、エラーを返す
- 5/27 ツクヨミ 1200-1500の予約は失敗し、1200-1300と1400-1600の予約
## issue
- 予約者マスターができて、adminの人だけツクヨミを予約できるようにする

今回のUseCase外の仕様の話が出てきたら、各チーム別でissueとして管理することで、議論の発散を防ぎました(issueは追加要件として後日採用)

当日のイベントの予定

自己紹介(1810~1820)
ユースケースの確認(1820~1830)
モデリング開始　名詞と動詞を抜き出す状態遷移図クラス図(1830~1930)
現状のモデルシェア、チームでfeedback(1930~40)
testcase通る想定まで実装とモデリング行き来(1940~2040)
KPT(2040~2050)
KPTとissueの共有(2050~2100)
懇親会(2100~2200)

当日の様子と各チームモデルとKPT

Aチーム

f:id:st5818129:20190528015441j:plain f:id:st5818129:20190528015805j:plain

Bチーム

f:id:st5818129:20190528015754j:plain f:id:st5818129:20190528015836j:plain

それぞれのissue

f:id:st5818129:20190528015825j:plain

(他にも状態遷移図や業務フローなど色々図を作成したのですが、写真を撮り忘れました、、)

反省点

それぞれのDDDの理解段階が違うことを顧慮すべき。最初にそもそもDDDとは、モデリングってどの層の話か、頻出単語集くらいは共有すべき
testcaseやdomain層以外の実装を終わらせておいて、スムーズにdomainと実装を行き来できる状況が作れなかった
少しスケジュールを詰めすぎた休憩をもうけるべきだった
図で表現する力の弱さを実感した積極的にUMLや状態遷移図などで表現する癖をつけるべき

終わりに

アーキテクチャ勉強会、初回ありがとうございました！こういう回を求めてる人がたくさんいてとても嬉しい😬
明日slackの方招待しますんで、今後ともよろしくお願いします🙇‍♂️
— nari@エンタメ系エンジニア (@fukubaka0825) 2019年5月26日

今回のusecaseでのモデリングは各チーム終了したので、次回開催までにテストケースを通すまで実装することとなります。
そこで生まれた反省点をモデルに反映しつつ、次回はissueを追加要件として、変更可能性について議論していきたいと思います！
— nari@エンタメ系エンジニア (@fukubaka0825) 2019年5月26日

初回は色々と反省点も多かったですが、こういった性質のイベントは長い目で見るべきなのかなとも思いました。

そして、やっぱりみんなでわいわい設計を実際しながら議論するのは楽しい！！！
(僕やその他酒好きは、懇親会に先立ち酒駆動設計してました笑) 　　

ここから実装や仕様追加しながら、みんなで仕様変更に強いdomainを育てる感覚を養っていきたいと思います。 (とりあえず、会議室予約システムというお題は継続する予定。簡単そうで意外と考慮すべき点が多く、かつ会議室と予約どっちをコアドメインにするかで違いが出る、良いお題でした。)

次回以降もレポ書いて、モデリング力を磨いていく仮定を記録していこうと思いますので、今後ともチェックしていってください。　

2週間に一回やっていく予定なので、参加型の設計イベントに参加してみたい、あなたのご参加もお待ちしております !　　

現状少人数ですが、知見が高まれば将来的に大勢で会議室を貸し切って、モデリング布教活動もやっていきたいですね。　

nariのエンジニアリング備忘録

SRE/Devops/AWS/自動化/IaC/Terraform/Go/DDD など

モデリングがやりたすぎて、アーキテクチャ勉強会を立ち上げてみた話

はじめに

アーキテクチャ勉強会発足のきっかけ

1.モデリングを定期的にやりたい欲が爆発した