犠牲的アーキテクチャとは

Martin Fowlerさんが2014年に提唱したソフトウェア開発の概念です。
https://martinfowler.com/bliki/SacrificialArchitecture.html

概要

現在書いている最良のコードは数年後には捨てるという事を受け入れる。
その上将来リプレイスする事を考慮した開発を行うという概念

googleでも犠牲的アーキテクチャ

実際、この指針を組織の行動原理に焼き込むこともできるだろう。Google では、現時点の十倍の負荷を捌けるようシステムを設計するのがはっきり定められたルールとなっている。負荷がある規模を超えたら現行の版を捨て、最初から作り直した方が良いという含みがここにはある [1]。サブシステム群を数年おきに再設計しては捨てるのが普通なのだ。

犠牲的アーキテクチャの採用をしている企業のメリットをいくつか書くと、

• 事業規模にあったパフォーマンスの維持
  ＊ 常に時代にあったその時の最適な技術を選択する為、
• 今のメンバーにノウハウを蓄積する

があるそうです。

具体的なアプローチ

初期のシステムなら丸ごと捨てるのも悪くないかもしれないが、システムが大きくなるにつれて個々のモジュールを捨てる方が良くなる。それができるのは、うまい具合のモジュール境界がある時だけだ。

との事なので
例えば、shopifyの様にrailsアプリでもユースケース単位でコントローラーを分割するのは良いアプローチだなと思います。
https://engineering.shopify.com/blogs/engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity

名言

出来の悪いコードの上に多すぎるユーザを抱え込むのはふつう、その逆よりもマシだ。