このテキストのトピックは、 1Cに関するよく知られた（Habréの） 記事で提供され、特に、機能的なボックス構成の開発に対する尊敬される企業のアプローチを強調しています。
私たちのプラットフォームは、モノリスの概念によって1Cと統合されています（ 一部の同僚のモジュール方式とは対照的ですが ）が、基本構成の構成に対するアプローチは、1Cと比較して1Cとはまったく逆です。
伝統的に、私たちは最初に言葉の意味に同意します。
著者に知られているすべてのERPシステムは、特定の「プラットフォーム」とそれに実装されたアプリケーションコードで論理的に構成されています。これは「構成」（1Cおよび当社）または「ソリューション」と呼ばれます。
著者を含むすべてのベンダー（当社を含む）は、プラットフォームの機能と基本的な構成/ソリューションを個別にサポートしています。
歴史的な理由により、基本構成で市場に参入した時点では、最初から開発されていた機能が完全に存在していました。 それより少し。
レクサスワンスのように：装備は1つだけで、最大
最初は非常に良かった-ソリューションを迅速に展開しました。 ただし、新しいクライアントごとに、新しい問題が発生しました。
理解するために-適用されたコード（つまり、構成/ソリューションコード）のボリュームは約15 MBでした。
ただし、構成コードの量自体は問題ではありませんでした。
問題は、基本構成の段階的な陳腐化でした。
新しい実装ごとに、新しい機能が発生しました。 以前に実装された機能との競合のため、基本構成に転送することはできませんでした。
当然の結果として、基本構成は強化も更新もされず、消費者の財産では徐々に失われました。
一方、実装プロセスでは、基本ソリューションの広範な広範な機能が問題になりました-展開される次のクライアントではほとんどが完全に冗長でしたが、複雑な相互作用による新しい機能の作成や古い機能の更新は正当化されませんでした（個々のオペレーターの観点から） 。
バグの生成という点でも危険です。実際、「役立った人はそれを知っています」が、トピックにあまり興味のない読者にとっては、類似したものがあります。 そして、同じ石で構成された山の斜面に「そのまま」置くと、雪崩災害に見舞われる可能性があります。
上記の基本構成を手にして、私たちは同僚の長い列に立っていました。基本ソリューションの最も飽和した機能を持ちたいという欲求は、ほとんどすべてのERPベンダーを結び付けます。
実装に関する同様の問題は、当然かつ必然的に発生します。 実際、問題は1Cに関する同じ記事で詳しく説明されています。
マーク・トウェインは、「あなたが多数派であるならば、慎重に考えてください。」と呼びました。
プラットフォームの第2世代を開発する際、後方互換性を拒否したため、いずれにしてもアプリケーションコードをゼロから作成する必要がありました。
そして-7つのトラブル、1つの答え-彼らはアプローチを「最大」機能から反対に変更することを決定しました：最小最小、親愛なる読者。 フィクションの目標はcです。
最小値は、多くの将来のすべてのオペレーターが要求する形式またはその形式に近い、最も簡潔な機能です。 事業の種類に関係なく。
私たち自身にとって、これを「インフラストラクチャ機能」と呼びます。商品、顧客、従業員、財務書類、原価計算、予算、キャッシュレス支払いなどのディレクトリです。
そのような機能は、時代遅れになった場合、非常にゆったりしています（私たちの実践では、2004年以降、重要な変更は検出されていません）。
彼は基本構成に含まれていました。
そしてのみ。
比較のため、 Ultima Businesswareプラットフォームの第2世代では、基本構成コードのボリュームは2 MBです。
実装とサポートに対するこのアプローチの利点は、非常に貴重で明白です。
ただし、最も豊富な機能の利点はなくなります（現実または架空-別のテキストの主題ですが、マーケティングの観点からは「豊富な機能」は間違いなくプラスです）。
ビジネスケースの装置を通じて「最も機能的な」機能を持つという問題を解決します 。それは、個々のクライアントに論理的に割り当てられた機能ブロックの実装と操作の結果です 。
ある意味では、それらの組み合わせは、経営上の意思決定の観点を含め、オープンな知識ベースです。
各ビジネスケースの機能は機能し、特に重要なことは、実際の生きているビジネスで発展します。
新しいクライアントが、インフラストラクチャの一部ではない別のビジネスケースまたはそのグループの機能を必要とするたびに、実際のコードがプロジェクト間で転送されます。 関連するnishtyakiタイプの自然コードレビューが暗示されていますが、簡単のために説明されていません。
プロジェクトが異なるパートナーによって管理されている場合、 ウルティマパートナーセンターがコミュニケーションをサポートできますが、原則として、その介入は不要です。
基本構成の単純さ（もちろん、 プラットフォーム開発ツールももちろん）により、外部機能を比較的簡単に統合できます。
もちろん、開発者には多少の努力が必要ですが、競合する機能を実装する場合に比べて比較にならないほど少ないです。
要約すると：
- ウルティマソリューションのメンテナンスは簡単です。
基本構成では、排他的に使用される機能があります。
「隠された」機能はありません。
設定とチェックのシートはありません。
- 実装されたソリューションの機能は常に関連しています。
「インフラストラクチャ」機能は老朽化しません。
コードの個々のセクションが何年も前に素数を取得してate化する可能性のある「豊富な基本ソリューション」とは対照的に、ビジネスケースの外部機能はその存在条件に関連しています。
実行中のビジネスでは、機能が進化します。 それがうまく機能するとき、それは急速に進化し、膨大な数の独立したアクター-従業員、 そして時には顧客の影響下にあります 。 最初は同じ機能が異なる顧客で異なる方法で進化するとき-出力は、さまざまな条件に対してさまざまな効率のソリューションの豊富なパレットです。
基本的な性質の明らかな理由により、これに近づくことさえできないベンダーはありません。
PS最初に戻る-モノリシックアーキテクチャの基本的な欠陥に関する1Cの記事に関する著者の苦情。
猫が料理できるなら、モノリシックな建築は素晴らしいです！