申込み時点で +100 人くらいで補欠だったので諦めてたんですが、 当日の 0:30 に繰り上がり通知が来て、慌てて参加しました。
全体を通して、いくつか印象に残ったことを書いておきます。
- 始める前にメンバーとの共通認識をつくる
- DDD の方法そのものの学習
- 業務知識の理解
- エンジニア以外のメンバーとの共通認識も重要
- 良い設計のためにはビジネスの理解が必要
- まったく新しく取り組む場合はリスクを小さくする
- 小さく始める
- 重要だが緊急性が低いもの
- 緊急性が高いと品質を犠牲に完成を強いる圧力がかかりがち
- ビジネスサイドへの説明は簡単ではないが大事
- 小さく始めると少ないコストで実績を積んで成果を確認できる
- 刷新前と刷新後のコードベースに対して同じ改修をして効果測定をした
説得のために刷新前と刷新後全く同じ機能を作って効果測定したらしい！すごい #genbadeDDD pic.twitter.com/xVcRCk8kfn
— 松岡@DDDブログ書いてます (@little_hand_s) 2019年5月11日
- 変化に弱い = レガシーになりやすい
- とりあえずマイクロサービスにすればいいというわけではない
- サービス分割がイケてないとやっぱりポシャる
感想
- 新規開発ではつまづかないような、レガシーと戦う上での知見が聞けてよかった
- チームで DDD に取り組むための心構えができた
- まだ仕事で実践できていないけど、学んだ内容の再確認ができた
- DDD は銀の弾丸ではない。レガシーとの戦いは泥臭い作業の繰り返しだ。
