10年ものの請求・受注基盤という「大きな泥団子」を、作った本人がドメイン駆動設計（DDD）で壊している話｜Tsubasa Tsuchiya

10年ものの請求・受注基盤という「大きな泥団子」を、作った本人がドメイン駆動設計（DDD）で壊している話 💡 この記事で言いたいこと ・ビジネスロジックが複雑な場合、いきなりコードを書かず、時間をかけてドメインモデルを整理した方がいい ・大きな商品プラン改訂の対応と、全面リファクタリングの同時並行は大変 ・10年ものの大きな泥団子も、8カ月で50回以上ドメインモデルを整理すればなんとかなる はじめにこの4月、Wevoxは大きな商品プラン改訂を行いました。それに伴い、請求・受注基盤を大幅に刷新することになりました。 この記事では、10年増設を繰り返し「大きな泥団子」と化した請求・受注基盤を、ドメイン駆動設計（DDD）の考え方で整理したプロセスについて書きます。機能性、変更容易性、ビジネス拡張性の高いシステムに変えるため、チーム全体で取り組んだ内容や気づきについてお伝えします。 おことわり

[carbon00]

事業が停滞してるか、優秀なチームが管理してない限り泥団子はいつの技術、時代でも簡単に生まれると思う。優秀なチームには意思決定者(層)が含まれている必要があって、エンジニアが自省してたら変わらないと思う。

[simplememofast]

自分も『今回だけ』の増設を重ねて泥団子を量産した側。原因はモデルより目の前の要求を優先したこと。8カ月かけ50回描き直す胆力が本質で、コードは後でいい

[strawberryhunter]

指示を出している人が内情を知らないと、こうなるのは変更量に応じた程度問題。自分でコントロールできたのにこうなったのなら自業自得だが。／個人的には変更容易性は自己満足でありYAGNI。

[ngsw]

このフェーズに来たことをもっと誇っていい。みんなで乗り越えようとしているならばなおさら誇っていい

[yarumato]

“まず、共通言語の定義から始めた。1つの対象物なのに見方によって別の意味を持つ場合、言葉を分けた（PartyとTenantなど）。Party（契約主体）、Order（受注）などビジネスロジックが正しく分離されていると変更が容易”

[hogetax]

“ドメインモデルの整理 - 8カ月で50回以上変えた”これどういう意味なんだろう？？？文章からだとよく分からんかった。すごく興味深い。境界を動かしたってことなんかな？

[guntz]

10年前って2016年。すでにモダンな設計できる頃だがそんなに泥団子になるモノなのかな？ 途中コロナで停滞期あるから実質5年くらいじゃね？