私が常に従おうとしている幅広い全体的なアプローチは、ドメインモデルを設計することから始めることです。これは「ユビキタス言語」であり、ビジネスオブジェクトと概念を定義し、ビジネスロジックを含み(後で使用する場合)、一般にシステムのさまざまな部分で使用される共通言語になります。
アイデアは、関係するすべての人が理解する(または少なくとも理解できる)必要があるということです。たとえば、他の部門のマネージャーの中には、リレーショナルデータベースや、自分の部門のデータをそこに保持することについて何も理解しているとは限りません。しかし、彼は自分の部門のビジネスプロセスを理解しています。彼らの言葉、彼らの概念、彼らの相互作用など。遍在する言語は、グループが共有する共通の基盤です。
このプロセスの間、あなたはあなたの心の前にあなたの依存関係を保つべきです。最大のものは通常、データの永続性です。ドメインモデルが一般に永続性を無視するか、依存関係を無視するという、ある種の黄金の夢があります。関心の分離を目的とするのは良いことです。ただし、真の依存関係の無知は、あなたを追い詰める可能性があります。深刻なパフォーマンスの問題やアーキテクチャの問題が発生し、後で多くの再設計が必要になる場合があります。
そのため、ドメインモデリングから離れて、永続性(および、使用する必要のある外部サービスや統合する必要のあるサードパーティアプリケーションなどの他の外部依存関係)について考えることがあります。ドメインをモデル化するときは、モデルが必要なすべてのもので適切に機能することを確認してください。依存関係の制限に対応するために、あちこちで遍在する言語について少し妥協する必要があるかもしれません。
基本的に、データベースを設計する前にドメインモデルを設計します。ただし、そのプロセス中にデータベースを忘れないでください。