ドメイン駆動設計では、小さなステップ（設計またはコードの変更、単体テストなど）を行うのが最適です。
これは、SQL Server ManagementStudioのSQLServerの（script =コードを書く）のは良いことだと思いますが、DDDを使用すると、設計をテストした後、最後にデータベースコードを記述します。
c＃で記述されたコードを使用して、EFを使用してデータベースを作成すると、c＃コードが頻繁に変更され、暗黙的にデータベースコードが大幅に変更されます。
どのように進めるのが最善ですか？
DDDは永続性の無知を説き、ドメインアーティファクト（エンティティのクラス、値オブジェクト）はそれらがどのように永続化されているかを認識してはならないことを示しています。ただし、技術的な永続性の懸念は、常に簡単に回避または遅延できるとは限りません。その結果、コード内のモデルは通常、永続化テクノロジーの制約の影響を受けます。
あなたはすでに最良のアプローチ、つまり小さなステップを予見しました。問題は、何がステップを構成するかです。最初のステップは、コードでモデルを設計してから、永続性を実装することで構成できます。次のステップでプロセスが繰り返されます。ステップが小さいという事実は、データベースよりもモデルに焦点を当てながら、すべてを簡単に永続化できないコードでデザインを作成する可能性を減らします。
SQL Management StudioとEFジェネレーターの使用に関しては、これは好みの問題です。私はSQLを手動でコーディングすることを好みますが、他の人はEFの生成機能を楽しむことができます。
ブラウンフィールドプロジェクトに取り組んでいると仮定します。次に、特定のユーザーストーリーについて：
1）ドメインモデルを設計して単体テストします。
2）次に、インフラストラクチャの統合テストを行います。これには、これらのテスト用に動的に作成されるデータベースに対するリポジトリ実装のテストが含まれます（メモリ内または埋め込みの場合があります）。NHibernateは、EFについてはよくわかりませんが、スキーマを自動的に生成します。SQLiteに対してテストできますが、たとえばSQL Serverに対して実行できるため、永続性にとらわれないことは間違いなくここで役立ちます。
3）次に、本番データベースの移行スクリプトを手動で作成します。このステップで役立つ黒い魔法はありません。スクリプトは、後でRoundhousEなどのフレームワークで実行できます。詳細はこちら。
すすぎ、繰り返します。まだデプロイされていないグリーンフィールドプロジェクトの場合は、ステップ3）をスキップして、最初の本番デプロイメントで「ベースライン」スクリプトを生成できます。