データベース内のドメインモデルは持続可能なソリューションになりますか？

私は、Microsoftテクノロジーをベースにした中小企業のデータベース開発者として新しい仕事を始めました。私は、ベストプラクティス、設計パターン、テスト、およびプロジェクト管理に関して、学校で教えられたものからどれだけのプラクティスが逸脱しているかに早く気づきました。

私を最も悩ませているのは、メインのデータベース開発者（以下、「ジョン」と呼びます）がデータベースにモデルスキーマを保持する方法です！これを行うには、3つの「マジック」テーブルを使用します。1つはデータベーススキーマ用、1つはテーブル用、もう1つは列用です。

レコードを「テーブル」テーブルに挿入すると、実際の対応するテーブルが（データベーストリガーを介して）生成されます。「Rows」テーブルに行を挿入すると、参照されているテーブルがその行で更新されます。これらは、彼の手作りのC＃プログラムによって順番に読み取られ、C＃モデルを生成します。これは、フロントエンド開発者がコントローラーおよび外部向けに使用します。

これとは別に、ほとんどの開発はASP.NET MVCフレームワークに従って行われます。

このアプローチにはいくつかの欠陥があります。

• ORMを維持するために彼が必要であり、そうする時間はめったにありません（ジョブのセキュリティは良いです！）
• 「テーブル」および「行」テーブルのトリガーに欠陥があります。テーブルの更新も、チェック制約や「高度な」機能もサポートしていません。それらを確実に改善することはできましたが、これが道筋かどうかはまだわかりません。
• データベース内のプログラムロジックを維持することは、奇妙で制限されているように感じます（ただし、C＃を使用してモデルを拡張することは可能です）。
• 彼のC＃モデルジェネレーターは、3人のうちの1人（私は1人）によって手動で実行する必要があり、まだ自動化されたビルドプロセスに含まれるほど成熟していません。

Entity Frameworkのような真のテスト済み製品への段階的導入を提案した人もいますが、彼はそれを却下し、ビジネスロジックをコード層に保持することは小規模なアプリケーションとスタートアップのブートストラッププロジェクトにのみ適していると主張しました。

この投稿は、意見を述べた議論のように見えるものに向かっていますが、それは私の意図ではありません。私たちのアーキテクチャのアプローチに関する明確化が必要です。

データベースにドメインモデルを保持することは、成長中の企業にとって持続可能なソリューションになりますか？

内部プラットフォームについて説明しています。

内部プラットフォームの問題は、数十年にわたる進化と努力で磨き上げられ完成されたプラットフォームまたはテクノロジー（この場合はリレーショナルデータベース）のすべてのメカニズムを再発明することですが、不十分な再発明です。従来の設計を選択したユーザーが利用できるすべての最適化をバイパスし、将来の複雑さと困難のために初期のシンプルさと優雅さを交換します。

そうは言っても、このプロセスの最終製品が、実際のビジネスドメインオブジェクトをモデル化した実際のテーブルと実際のクラスである場合、ツールの未熟さを除けば、このアプローチに大きな害はありません。Stack Exchangeは実際に独自のORMを使用しており、それは彼らにとってうまくいったようです。したがって、これらの種類の「コテージ」アプローチが機能することを知っています。

「テーブル優先」アプローチをとるほとんどのORMは、データベース内のテーブル構造を見てクラスを作成するだけです。友人が作成した「テーブル」および「行」テーブルは、ほとんどの最新のリレーショナルデータベースシステムのシステムテーブルに既に存在するメタデータにすぎません。

さらなる読み物
「Vision」プロジェクトは、内側のプラットフォーム効果に関する注意書きです_{（前書きを飛ばして、「Introducing Vision」の}見出し
_{から読み始めることができます）。}