自分も『今回だけ』の増設を重ねて泥団子を量産した側。原因はモデルより目の前の要求を優先したこと。8カ月かけ50回描き直す胆力が本質で、コードは後でいい
10年前って2016年。すでにモダンな設計できる頃だがそんなに泥団子になるモノなのかな？ 途中コロナで停滞期あるから実質5年くらいじゃね？
“ドメインモデルの整理 - 8カ月で50回以上変えた”これどういう意味なんだろう？？？文章からだとよく分からんかった。すごく興味深い。境界を動かしたってことなんかな？
事業が停滞してるか、優秀なチームが管理してない限り泥団子はいつの技術、時代でも簡単に生まれると思う。優秀なチームには意思決定者(層)が含まれている必要があって、エンジニアが自省してたら変わらないと思う。
“まず、共通言語の定義から始めた。1つの対象物なのに見方によって別の意味を持つ場合、言葉を分けた（PartyとTenantなど）。Party（契約主体）、Order（受注）などビジネスロジックが正しく分離されていると変更が容易”
このフェーズに来たことをもっと誇っていい。みんなで乗り越えようとしているならばなおさら誇っていい
指示を出している人が内情を知らないと、こうなるのは変更量に応じた程度問題。自分でコントロールできたのにこうなったのなら自業自得だが。／個人的には変更容易性は自己満足でありYAGNI。
10年ものの請求・受注基盤という「大きな泥団子」を、作った本人がドメイン駆動設計（DDD）で壊している話｜Tsubasa Tsuchiya
自分も『今回だけ』の増設を重ねて泥団子を量産した側。原因はモデルより目の前の要求を優先したこと。8カ月かけ50回描き直す胆力が本質で、コードは後でいい
10年前って2016年。すでにモダンな設計できる頃だがそんなに泥団子になるモノなのかな？ 途中コロナで停滞期あるから実質5年くらいじゃね？
“ドメインモデルの整理 - 8カ月で50回以上変えた”これどういう意味なんだろう？？？文章からだとよく分からんかった。すごく興味深い。境界を動かしたってことなんかな？
事業が停滞してるか、優秀なチームが管理してない限り泥団子はいつの技術、時代でも簡単に生まれると思う。優秀なチームには意思決定者(層)が含まれている必要があって、エンジニアが自省してたら変わらないと思う。
“まず、共通言語の定義から始めた。1つの対象物なのに見方によって別の意味を持つ場合、言葉を分けた（PartyとTenantなど）。Party（契約主体）、Order（受注）などビジネスロジックが正しく分離されていると変更が容易”
このフェーズに来たことをもっと誇っていい。みんなで乗り越えようとしているならばなおさら誇っていい
指示を出している人が内情を知らないと、こうなるのは変更量に応じた程度問題。自分でコントロールできたのにこうなったのなら自業自得だが。／個人的には変更容易性は自己満足でありYAGNI。