大規模な機能プログラミングアプリケーションの作成に一般的に使用される特定のワークフローまたは設計パターンはありますか？[閉まっている]

Clojureをしばらく使ってきましたが、重要なプロジェクトでは使用していません。基本的に、構文といくつかのイディオムに慣れてきました。OOPのバックグラウンドから来て、Clojureが私が非常によく見た最初の関数型言語であるため、私は当然、物事の関数型の方法にそれほど満足していません。

とはいえ、大規模な機能アプリケーションの作成に共通する特定のワークフローやデザインパターンはありますか 「実際に」関数型プログラミングの使用を開始したいのですが、現在の専門知識の不足により、大失敗に終わるのではないかと心配しています。

「4つのギャング」はOOプログラマーにとって非常に標準ですが、機能的なパラダイムにより向けられた類似のものはありますか？私が見つけたほとんどのリソースには、優れたプログラミングナゲットがありますが、一歩踏み込んで、より広範な、よりアーキテクチャ的な外観を与えることはできません。

この種のパターンは通常、壊れた、不適合な基礎モデルの症状です。

OOPは設計上壊れており、ほとんどのアプリケーションには適していないため、いわゆる「パターン」であふれています。機能モデルは（ほんの少し）より柔軟であり、「パターン」の必要性はそれほど明白ではありません。

特定の問題ドメインごとにDSLを使用または作成する（関数型プログラマにとっては自然な）言語指向のアプローチを適用し始めると、常に適切なモデルを採用しているため、パターンがまったく表示されないことがわかります。問題の説明。

もちろん、いくつかの高レベルの「パターン」または「レシピ」は、非常に抽象的でクリーンで純粋な数学でも避けられませんが、GoFパターンとは種類が異なり、抽象化のレベルも異なります。たとえば、モナドは便利です。

私見では、デザインパターンはセマンティックです。パターンを理解したことを確認するためだけに、MVCを使用して古いアプリの一部を書き直したことを覚えています。しかし、最終的には、MVCから元のコードに対して何も得られませんでした。

ただし、元のコードをより大きな開発環境に適用し、この特定の方法に問題があることを誰かに伝えるとしたら、その開発者が問題を追跡するのは難しいでしょう。ただし、何らかの理由でContractControllerが台無しになったと言ったら、どこから始めればよいかが正確にわかります。

設計パターンは素晴らしい...しかし、私が言ったように、それらは意味論的だと思う！

編集：あなたの伝道者のタイプは私をクラックします。MVC（または他のデザインパターン）なしで何かが開発されたのはどうしてですか！