>>353
> ややこしい業務ロジックが色々あるときはどうしてる？

ややこしい業務ロジックなどない。っていうのが答え。
処理が多くて面倒くさいだけだろう？

もしくは設計が必要な部分（フレームワーク）と
設計が必要ないような些細な部分が、ごちゃまぜになってる。
フレームワークを使ってなさそうだし、綺麗に分離できてないんだろう。

ちなみに「設計が必要ないような些細な部分」といったが
この部分が重要ではないという意味じゃないぞ。
むしろ顧客にとっては（当然だが汎用的なフレームワークより）
この部分の方にこそ価値があって重要な部分。

重要だからこそ、出来る限り汎用的な部分をそぎ落として
改修が入るコードのみにする。そこまで削ぎ落とすから設計なんぞ不要。
フレームワークを使うことで設計はどこかの誰かがやってくれるから
通常の開発で設計なんぞ、終わってることだから、やらない。

あんたは、この改修が入る部分と設計が必要な部分をあわせたままやってるから、
ロジックの改修時に設計をどうするかって話がでてくる。