有用なアーキテクチャ間の衝突について

Webアプリを構築するためにフレームワークや既存CMSを使うケースがありますが、それぞれに適したアーキテクチャがあります。通常、小さなシステムでは一つのアーキテクチャで貫徹できますが、その分、他のアーキテクチャを組み入れる余地が少なく、大型のフレームワークはアーキテクチャの縛りが少ない半面、内部アーキテクチャにブレが生じることがあります。
実装時には、ビジネスロジックが小型のフレームワークに完全に合致しにくいため、"よく動く"システムを安価に構築するにはビジネスロジックをフレームワーク側に合わせて行く方が効率がいいことがあります。ところがビジネスロジックの主と開発元が取引する場合、フレームワークにビジネスロジックを合わせるという話は「開発力のなさ」と受け取られることもあるので、フレームワークに手を入れてビジネスロジックに合わせる方が総合的には現実的だったりします。現実的という言葉を、非理想的という意味で使ってはいけないのかもしれませんが。
いずれにしても、いくつかのアーキテクチャはそれぞれに有用なものですが、混合することでそれぞれの良さを食いつぶしてしまうケースは多いような気がします。互換性に関する議論というのも必要かもしれません。
その点、何をしたいかと、実装とが同居しているベンチャーの場合はどの実装方法が最適かという議論を俯瞰的に判断できるため、思いのほかおもしろいシステムを組めたりします。大きな企業間取引でもその辺の事情を理解して、小さめのユニットで作業させればいいのかもしれませんが、それが実践できている現場には遭遇したことがありません。とはいえ、それほど多くの事例を体験しているわけじゃありませんが・・・
問題がフレームワーク内部であれ、受諾開発であれ、アーキテクチャの衝突はいろんなところで起きているなぁという雑感を持っています。