次のような状況があるとします：複数の開発グループが同じプロジェクトに取り組んでいますが、異なる問題を解決しています。 たとえば、プロジェクトはチップ設計者であり、最初のチームはチップを呼び出す機能を実装し、2番目のチームはチップのコストを計算します。 質問：より良い方法-1）両方のチームが出力で2つのモジュールを受け取り、そのコードが実際にはどこにも交差しないようにする、または2）2つのチーム間の通信を確立し、一緒に動作させて単一の出力を得るモノリシックシステム？ この質問に対する普遍的な答えはありません（yesまたはno）。象と賢者の類推は、この状況で答えを見つけるのに役立ちます。
ここでは、象は複雑な主題領域であり、賢者はプログラマーです。
白髪の6人の賢者
さまざまな国から集まった。
残念ながら、誰もが盲目でした
しかし、心は輝いた。
彼らは象を探検します
ヒンドゥスタンに登場。
象の側面をstrokeでた。
それに満足し、
彼は言った：「真実は今
日が見えるので：
象と呼ぶもの
薄手の壁！」
そして、3番目のトランクが占めました
そして叫んだ：「友達！
私たちの質問はもっと簡単です、
私はこれを確信しています！
この象は生き物です
つまり、ヘビだ！」
つかんだ4番目の賢者
象の足の1つ
そして彼は重要なことを言った：「これはトランクです、
写真は私には明らかです！
象は咲く木です
春が来たら！」
一方、それらの6番目
私は尾に着いた。
そしてそれを笑った
真実は簡単です。
「あなたの象はロープです。 そうでない場合
口を縫う！」
そしてあなたが知っているように、賢者
固有の頑固な性質。
議論を解き放ち、彼らは
報復前。
しかし、誰も真実を知らなかった
彼はやや正しかったが。
プログラマーのチームのサブプログラム（賢者）がサブジェクトエリアの特定の部分（象の足で）と対話する場合、サブジェクトエリア全体（エレファント）全体を知る必要はありません。 同時に、対象エリアのこの部分を単純化し、余分なものをすべて捨てる（象の足を木に変える）と、対象エリアにあまり慣れていない人（象が何であるかを知らない）でも理解できるコードを受け取ります。 さらに、サブジェクト領域が複雑すぎる場合、内視線で広大さを把握しようとすると、プログラマーは認知障害に陥り、開発速度が一桁低下します。 しかし、一方で、このアプローチはプログラムの個々の部分間の相互作用を複雑にします。
両方のアプローチを比較してください。 したがって、大規模なコンテキスト（モノリシックシステム）の利点：
•可能な限り多くの異なるオブジェクトと操作が1つの統合モデルでカバーされる場合、さまざまなユーザー操作がよりスムーズかつ自然に相互接続されます。
•2つの異なるモデルとそれらの間の表示レベルよりも、1つの接続されたモデルを理解する方が簡単です。
•2つのモデル間でのブロードキャストは困難な場合があります（不可能な場合もあります）。
•共通言語は、開発チームの明確な相互作用を促進します。
小さなコンテキストの利点（多くの異種モジュール）：
•開発者間の通信コストが削減されます（通信自体が少ないため）。
•継続的な統合は、小さなコードベースの小さなグループで簡単に実行できます。
•より大きなコンテキストでは、より普遍的で抽象的なモデルが必要になる場合があり、めったに遭遇しない開発者の資格を必要とします。
•小規模モデルは、特別なニーズに対応したり、専門的なユーザーグループの専門用語や、統一言語（UBIQUITOUS LANGUAGE）の高度に専門化された方言に対応したりできます。
理論的には、蛇、木、ロープが象に進化する可能性があることにも注意してください。 たとえば、プログラムの仕様が変更され、象が歩くことができることが判明した場合、木は足に変わる可能性があります。 ただし、すべてがそれほど単純ではありません。 サブジェクト領域の部分がどこでも交差しない場合は理想化されていますが、実際にはそうではない可能性が高いです。 プログラマの2つのチームが象のトランクを操作していると仮定しますが、最初のチームはトランクが生き物の特性を持ち、トランクが蛇であるという事実に関心があり、2番目のチームはトランクが水をはねかける能力に興味があり、トランク-水ホースがあるとします。 時間が経つにつれて、両方の開発チームは、偶然にも、最初のチームの蛇と2番目のホースが同じ現象を説明していることを認識し、その後、2番目のチームは蛇の吐き水でホースを交換することにしました。 そして、これには2週間のリファクタリングが必要になります。 私自身の経験から、プロジェクトが技術的負債の負担に沈み始めない限り、2週間何もさせてくれないと言いますが、それでもこの2週間はホースを吐く蛇に変えるよりも多くの差し迫った問題を解決します。 したがって、ロシアの開発の現実では、最初にモノリシックモデルに移行しなければ、モノリシックのままにすることは問題ではありませんが、モノリシックモデルに切り替えることはほとんど不可能です。
多くの無関係なモジュールのパスを選択した場合、次のことわざを覚えておいてください。「プログラマの3つのチームがコンパイラを開発すると、出力で3パスアルゴリズムを取得します。」 これに注意してください。 プログラムのアーキテクチャは、会社の内部構造ではなく、サブジェクト領域を反映する必要があります！
PSこの記事は、 この記事の小さなホリバーへの答えとして生まれました。 実生活の例が興味深い場合は、記事Multilevelの原則に対する管理されていない違反を読むことをお勧めします。