ぐるぐるDDDで気をつけてること
はじめに
この記事は、ドメイン駆動設計 Advent Calendar の2日目の記事です。
1日目は、@tanaka9230 さんの 「DDD」にまつわる諸課題の整理でした。
3日目は、@bigwheel さんの 集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話です。
ぐるぐるDDDとは
ぐるぐるDDD で検索すると、@haradakiro さんの資料がみつかると思います。
DDDとScrumを回していくことで、モデリングと実装をしていくやり方です。
ドメイン駆動設計というとどうしても実装の話が多いので、どうやってやっていくと、モデルと実装の乖離を減らしつつ、要求に答えられるシステムを開発出来るのか、 自分が気をつけてることを書きたいと思います。
モデル探求のうずまき
この絵は、端的にシナリオとモデルとコードによる探査をどのように扱うかを表しています。
注目してほしいのが、うずまきがシナリオ、モデル、コードによる探査それぞれにもあるところです。
どうしても大きいうずまきが注目されがちですが、各個のうずまきが回らない、停滞してしまうと前に進めることが出来ません。
気をつけてること
停滞させないように以下のことを気をつけてます。
- 捨てやすいように設計及び実装する。
- シナリオでどんなイベントが発生して、どのような状態になるかを考える。
特に捨てやすいように設計しておくことで、シナリオでモデルを揺さぶったときに変更が生じても影響範囲を特定しやすかったり、 必要なくなった場合はサクッとコードごと消したり、機能フラグを切り替えたりすることで、いつでも消せるようにしておける余裕をもたらすことが可能になります。
また、ストラングラーアプリケーションのように、捨てやすいようにしておくことで、 時間が経過したとしても、フェードアウトしやすいので無駄にヘイトを貯めることが減ります。
何をもって捨てやすいかは、システムの規模や実装言語などによって定義しにくいとは思いますが、ぐるぐるDDDを回す上でタイムボックスを守れる、 長期にわたってもいつでも消せる状態にあるというのは、要素として上げられるのではないかと思います。
あと、ドメインイベントはimmutableであるという制約を元にシナリオを読み解くことで、
リプレイする際にどの時にどの状態になるかということが何度でも確認できたり、
その時のシナリオでは漏れてたであろうドメインイベントを浮かび上がらせることが出来ると思います。
おわりに
今のプロダクトにも技術的負債は残ってますし、捨てやすい設計になっている箇所はまだまだ少ないです。
それでも、自分がこのぐるぐるDDDがあっていると感じるのは、全て携わって業務の理解がそのままコードになっていくことが改善に繋がっていく体験がとても楽しかったからです。
このぐるぐるDDDの無限に続くうずまきが描く軌跡が黄金の回転になる日がいつか来るでしょう。
