現在の証拠は、正規データモデルよりもコンテキストデータの採用をサポートしていますか？

「標準」の考え方はソフトウェアに広まっています。Canonical Model、Canonical Schema、Canonical Data Modelなどのパターンは、開発中に何度も登場するようです。

多くの開発者と同様に、私は頻繁に、批判的ではないが、正規モデルが必要であるという従来の知恵に従いました。それ以外の場合は、マッパーとトランスレーターの組み合わせの爆発に直面します。または、少なくとも、数年前にやや悪名高いEFの「自信なしの投票」を初めて読んだときまで、私はそれを行っていました。

正規データモデルの追求をかつて支持していたという仮説は、そのアイデアが実践されたときに発見されるであろう要因を含まず、含めることもできませんでした。長年の試行錯誤の結果、正規データモデルが使用される可能性のある個々のコンテキストに個別のモデルを使用することが、最も複雑なアプローチではなく、最もコストのかからないアプローチであり、保守性と拡張性の向上につながります。コンテキストモデルを使用したアプリケーションとエンドポイントの比較。これは、正規モデルが行うソフトウェアエントロピーを促進しないアプローチです。

エッセイはその主張を裏付けるいかなる種類の証拠も提示していませんが、代替案を試すのに十分長い間CDMアプローチに疑問を投げかけ、結果のソフトウェアは文字通りまたは比喩的に爆発しませんでした。しかし、それだけですべてが孤立しているわけではありません。運が良かっただけかもしれません。

ですから、ソフトウェアシステムまたはアーキテクチャに標準モデルとコンテキストモデルを組み合わせた場合の実際的な長期的な影響について、真剣な調査が行われたのでしょうか。

あるいは、それを尋ねるのが早すぎる場合は、開発者/アーキテクトに、CDMから独立したコンテキストモデルへの（またはその逆の）CDMから個人的なエクスペリエンスへの切り替えについて書いてもらい、生産性、複雑さ、信頼性などの実際的な影響は何でしたか？

異なるレベルでの違いについてはどうでしょうか。つまり、単一のアプリケーションで同じモデルを使用する場合と、アプリケーションのシステムまたは企業全体で使用する場合の違いはどうでしょうか。

（事実のみ、お願いします。戦争の話は大歓迎ですが、憶測はありません。）

EF不信任投票の記事に対応して、Tim Mallalieuは次のように書いています。

「標準スキーマ」でのXSDの使用を伝道していた時代に戻ることをお勧めしません。これは扱いやすいと人々が思っているとは思いません。ただし、多くのドメインモデルを記述できる単一のメタモデル（必要に応じてEDM）があり、単一の文法を使用することにより、与えられたドメインモデル。

たとえば、600のテーブルを持つデータベースに対して作成されるアプリケーションを考えてみます。このアプリには、600のエンティティタイプを含む単一のモデルが含まれている必要があると思いますか？いいえ...さらに、特定のドメインエンティティ（たとえば、顧客）はそのアプリで1つの図形のみを持ち、この図形はエンタープライズ全体の標準的な図形である必要があると思いますか？...いいえ。

Canonical Modelに関するWikipediaの記事は、Enterprise Service Bus、Service-Oriented Architecture、CORBAなどについて言及しています。それらはすべて、企業のデータの急増と通信の課題に対する解決策として提唱されました。^TM 彼らは成功しましたか？それとも彼らは自重で倒れたのでしょうか？

あなたは個人的な経験を求めたので、それをあげます。航空宇宙産業では、テレメトリをよく使用しています。テレメトリシステムの課題の1つは、異なるテスト範囲がテストデータを互いに有意義な方法で通信する方法を見つけることです。一般的な用語のデータディクショナリを定義しようとするまで、その問題は十分に単純に思えます。

「高度」とはどういう意味ですか？それは地上の高さですか、それとも海抜ですか。潜水艦について話している場合はどうなりますか？次に、高度ではなく、その深さ。陸軍にとって、「トランスミッション」という言葉の意味は、レーダーアンテナを指す場合と地上ベースの車両を指す場合では異なります。航空機を回転させる翼面は、一部の飛行機では「エイロン」と呼ばれ、他の飛行機では「エレボン」と呼ばれます。

それは、続く問題の山のほんのヒントにすぎません。データ通信には標準がありますが、テスト範囲はそれぞれ異なり、ニーズ、目標、優先順位も異なります。標準は、同じ範囲の異なるプロジェクト間でも異なる場合があります。このため、テスト範囲は、ソリューションがすべてを単一のモノリシックシステムに置き換えることによってではなく、単純な通信プロトコルに同意し、1つの範囲の語彙を別の語彙に変換する方法を提供することによって得られることを理解しています。

大企業が直面する問題も同様です。マイクロソフトはモノリシックに考える傾向がありますが、それは彼らの会社が概してモノリシックであるためです。文化やビジネスの方法が大きく異なるさまざまな企業間で（または同じ企業内の異なる部門間でさえ）通信する必要があるとすぐに、すべてを支配する1つのリング。^TMはすぐに故障し始めます。