開発者はドメイン駆動設計(DDD)のコンテキスト境界という概念を使って、巨大なモデルを複数の小さなモデルに分割できる。MSDN MagazineのJulie Lerman氏の記事によれば、このときにEntity Frameworkのデータベースコンテキスト(DbContextクラス)が利用できる。
ひとつのコンテキスト内で多くのクラスから構成される単一のモデルを使うのではなく、複数のモデルに分割するのは役に立つ、と氏は言う。氏は2003年よりMicrosoft MVPを受賞しており、.NETプラットフォームのコンサルタント、メンターとして活躍している。コンテキスト境界の概念を導入すれば、より小さくて凝集度の高いモデルが作成できる。氏の記事はこの考えに基づいているが、DDDのコンテキスト境界はDbContextクラスを使うことよりも広範囲の概念であることも指摘している。それゆえ、氏は自身の実装がDbContextに“はまっている”、や“特化している”と表現している。
顧客サポートのクラスを注文や発送のクラスと分離し、別々のDbContextクラスに置くことで、氏はアプリケーションのすべてのクラスを含む大きなコンテキストを小さくよりフォーカスが絞り込まれたコンテキストに分割する。基底にある大規模なデータモデルとデータベーステーブルは元のままだ。
クラスにコンテキストに必要ない属性がある場合、元のクラスの一部分と一部のデータベーステーブルをカバーする小さくてより絞り込まれたクラスを作れる。これはデータベースのビューを使って実現できる。これらのクラスの制約は、クラスが制御していない、nullを許容しない列がある場合、インサートできないことだ。DbContextは例外を発生させる。
テーブルの自動作成を使ったデータベースのセットアップ、“コードファースト”には、“上部モデル”とすべてのクラスを含むDbContextに追加の作業が必要だ。出来上がったコンテキストはデータベースを初期化するのに使う。
DDD本の著者であるEric Evans氏氏はこの記事に積極的にツイートしたが、このような方法でコンテキスト境界を適用することに懸念を示す人もおり、他の方法を提案している。DDDコミュニティの定義から外れた使い方だという指摘がされた。
“明示的にコンテキストを定義しモデルに適用する。チームやアプリケーションの特定の部分の使い方、コードベースやデータベーススキーマなどの物理的な条件を考慮して明確に境界を設定する。モデルがこの境界内で厳密な一貫性を持つようにし、外部の問題で混乱しないようにする。”
Entity FrameworkはMicrosoftの.NETプラットフォーム向けのオブジェクトリレーショナルマッパーだ。