こんにちは、在庫システムの新しいプロジェクトがあるとしましょう。私はJavaを使用します。私はクライアントにいくつかの要件を収集しに行き、それらを収集した後、それらの要件をモデル化します。最初に何をすべきですか？私のクラス図/ドメイン モデル? またはデータモデル？なぜ？これについてあなたの意見を本当にお願いします。ソフトウェア開発では、現実の世界で何をしていますか?
これらの技術を使用しています：Java、Hibernate（ORM）、スクラム（方法論）、postgresql（データベース）
3 に答える
2
最初にどちらかを実行しないでください。ドメイン (オブジェクト) モデルと ER モデルを並行して作成します。ER モデルはデータのみに関係しているのに対し、ドメイン モデルはデータと動作に関係している点を除いて、それらは非常に似ている必要があります。
ただし、専門家でさえ多くの開業医が陥る落とし穴を避けるために、細心の注意を払う必要があります。それが分析と設計の混同です。ドメイン モデルと ER モデルの両方が、設計モデルではなく分析モデルである必要があります。つまり、ソリューションを設計するときに追加する機能ではなく、問題と要件を説明することを意味します。
特に、このフォーラムで見られる ER 図の多くは、ER 表記法を使用していても、実際にはリレーショナル データ モデルです。また、外部キーなどの設計機能が組み込まれており、情報要件に固有の機能に限定されません。
設計を開始する前に要件をかなり正確に特定できないことは、大規模なプロジェクトの失敗の主な原因です。小規模プロジェクトでは、それほど多くはありません。
于 2013-07-14T19:33:07.587 に答える
1
IMO は、最初にデータ モデルについて考え始めるべきではありません。
その理由は、すべてのビジネス ニーズに対処するのはドメイン層次第だからです。
ドメイン層は不可知論的でなければなりません。特定の技術的実装に結び付けたり、いかなる種類のフレームワークを参照したりしないでください。自己完結型で、単独で機能する必要があります。ドメイン層を設計するときは、永続性やデータの表示方法についても考えないでください。データを保存するメソッド、または のような特定の UI コンテナーから情報を収集するメソッドが必要な場合はSession、単に を使用してInterfacesください。
データ モデルを設計するときは、データの格納に使用する RDBMS に縛られます。データを効率的に格納およびアクセスするためにスキーマを構造化する方法について考えます。しかし問題は、ビジネスはクエリのパフォーマンスを気にしないということです。
可能であれば、UI、フレームワーク、データベースなどの重要な決定を延期することは常に良いことです。そうすれば、ビジネス ニーズのみに集中できます。
于 2013-07-15T09:34:38.723 に答える