トーク

弊社では物流Techとして物流業界の様々な課題を解決しようと奮闘しています。
今回はその中でも注文情報周りを扱う処理が肥大化してしまい、変更がどんどんと困難になってしまった話をします。
注文情報というのは各ECプラットフォームから取得される情報で、どこに配送するかや、なにを配送するかなど多くの情報を持っています。
また、配送済みかどうかや、そもそも弊社倉庫から出荷するのかなど、更に内部の状態を複数持つことになります。
DDDライクな設計で実装を進めていましたが、最初は保存処理などシンプルなもののみをOrderRepositoryとして実装していたので、特に問題はありませんでした。
しかし、どんどんと機能仕様が膨れ上がり、注文が持っているべき状態というのもそれに伴って増えていきました。
注文の状態を更新するために他のテーブルの状態を見ないといけなくなり、そのロジックをトランザクションの中に入れようとした結果記述量が増えたり、
注文の状態が変わったことをeventで通知するのをすべてRepository層でやったことで抜けが発生したりと、だんだんとOrderRepositoryが太っていきました。
また複雑になっていくことで、機能追加するたびに他の機能の変更を気にしなければいけない状態になっており、同時に機能開発をしているとコンフリクトと戦う時間が増えてしまうという問題もありました。
そんなOrderRepositoryとどうやって向き合って、どうやって綺麗にしていったかの話をしていきます。