モデリングパラダイム
こんなトピックがあったのかと、改めて読んでみました。
基本は、広く使われてもいるオブジェクト指向設計でのモデリング。
ここまで広まった理由はシンプルかつ洗練されているから。ドメイン駆動設計では、技術寄りでないメンバーも参加する。
チームにいる技術よりでないメンバが、少なくともパラダイムの初歩を把握することができなければ、モデルを理解することもできず、ユビキタス言語が失われることになる。(第ニ部 第五章 より)
さらに、インフラストラクチャのツールサポートも充実している。開発者も見つけやすい。
他のパラダイムとの混合
プロジェクトにおいて、支配的なモデルパラダイムが何であれ、ドメインの中には、他のパラダイムならばはるかに容易に表現できる場所が必ずあるものだ。(第ニ部 第五章 より)
こういうときに、例えばルールエンジンやワークフローエンジンなんかは統合しやすいと言っています（使ったことはないですが・・・
ルールエンジンを使用する場合、こういったルールとオブジェクトをシームレスにつなぐ環境が必要になります。最も効果的なツールはユビキタス言語。モデル駆動設計に忠実であることがコツになりそうですね。
RDB
このパラダイムは特殊。なぜならオブジェクトそのものを構成するデータの、永続ストレージとして機能するからです。
６章のレポジトリで詳しく解説されると思います。
RDBのパラダイムはオブジェクト指向のパラダイムとは別のパラダイムとして（当然）上げられています。
ゆえに、オブジェクト指向のパラダイムで作られたドメインのモデルとRDBのテーブル設計・モデルは別物であるということですね。
RDBのテーブルとモデルを関連付ける、RailsのActiveRecordはモデル駆動設計をするのには向いてないフレームワークといえるかもしれません。