大きなプロジェクトのクラスを適切に設計するにはどうすればよいですか？
まだ完全に設計されていない大規模プロジェクトのクラス図でクラスを表す必要があり、クラスがデータベース内の実際のテーブルでなければならない場合、クラスをどのように予測および設計しますか？
15以上のテーブルを持つプロジェクトがあるとしましょう。これらのテーブルはすべてクラス図のクラスである必要がありますか？
このような状況でクラスはどのように設計されますか？使用されている言語はJavaであり、クラス図はUMLで準備する必要があります。それらを設計する方法を知っています。この場合、テーブルがクラスを表す必要があるかどうかわかりません。 。
テーブルを直接マップするようにクラスを設計することは、アンチパターンと見なすことができます。自然なオブジェクト-OOおよびリレーショナルDBを使用する場合に発生するリレーショナルインピーダンスの不一致があります。
多くの場合、データストレージから独立したドメインに従ってアプリケーションを設計することをお勧めします。 ドメイン駆動設計 は、このようなテクニックの1つです。
15を少し超えるテーブルがある場合、それは大きなプロジェクトではないようです。しかし、主要なポイントは、どの開発アプローチと設計を計画しているのですか？
データモデリング クラス設計の前に行う必要があります。データモデリングを実行している間、引き続き アーキテクチャモデリングテクニック に取り組むこともできます。考慮すべきいくつかの選択肢があり、それらはすべてプロジェクトの仕様に依存します。 ERダイアグラムなどのツールは、低レベルのクラス図だけでなく、高レベルの設計にも役立ちます。
アプリケーションの種類によっては、オープンソースプロジェクトのサンプルからクラスを構築するためのヒントが得られる場合があります。重要なポイントを述べさせてください。プロジェクトが進むにつれて、要件や設計によっては、構造を少し変更したり、レイヤーを追加したりする必要がある場合があります。
参考になる参考資料がいくつかあります。
一般的に、私はノーと言うでしょう。テーブルの構造を反映するDTOクラスを用意することを検討する必要がありますが、その唯一の用途はデータの転送です。アプリケーションが必要とする特定の機能をサポートする永続層には他のクラスが必要です（たとえば、複数のCustomerインスタンスを含むAddressクラスがある場合があるので、顧客は、関連付けられたアドレスも取得する必要があります。すべてのデータアクセスはDAOまたはマネージャークラスから行う必要があるため、すべてのアプリケーションは顧客の作成または使用について心配する必要があります）。ビジネスロジックが、データが格納されているテーブルについて心配する必要がある場合、それは間違っています。
ユースケースモデリングとプロセスモデリングから始める必要がありますが、クラス図から始めることはできません。
プロセスは、エンティティが互いにどのように関連しているかを教えてくれます。
実際、通常、すべての永続クラスを1つの図に含める必要はありません。その背後にストーリーはありません。これは素晴らしい家族の絵です。おそらくシステム要素を後で追跡するのに役立つと思いますが、通常、UML図には15を超える要素を含めないでください。設計エラーを見逃してしまうためです。 。
システムをルービックキューブとして想像してください。ルービックキューブを解く方法を理解するために、通常は1つ、2つ、または3つの側面を調べます。キューブを平らにしないでください！
すべての単一の図は、システムに関するストーリーを伝える必要があります。おそらくそれは、クラスのファミリーの分類法を示します。おそらく、システムが異なるアクターによってどのように使用されるかを示します。おそらく、特定のシナリオがどのようにプレイされるかを示します。特定のオブジェクトのセットは、問題を解決するため、またはコンポーネントが内部でどのように構造化されるかを相互に相互運用します。
そのため、通常は多くの小さな図を用意する必要があります。おそらく、特別なツールを使用してそれらをまとめることができますが、あなたは人間であり、ほとんどの同僚は人間でもあるので、一度にシステム全体。
（アジャイルのような他の方法論とは対照的に）ソフトウェアエンジニアリングにおける最大の課題の1つは、自分の頭蓋骨が限られていることを受け入れることです。あなたが10 + -5のことを把握できること、それだけです。ズームインまたはズームアウトするか、詳細を非表示にするか、キューブを回転させるか、一般的に何かを行う必要があります。
単一の巨大なクラス図として設計され、重大な設計エラーが含まれていなかったアプリケーションをまだ見つけていません。10分間図を見るだけで、または-通常は-変更ログを見るだけで表示されます。深刻な変更が行われなければなりませんでした。
私は通常、最初に各ユースケースのデータフローを描くように言います。どのデータが入ってくるか、どのデータが出てくるか、結果を得るために必要なデータはどれですか。次に、各ステップでどのような問題点があるかを尋ねます。
永続的なクラスの大きな家族のポートレートを撮影する-これはかなり制限されています。もちろん、これらのフローダイアグラム上で永続化する必要があるクラスを収集する必要がありますが、ツールがそれを実行する方が良いでしょう。
デザインは、特定の実装をどのように解決するかではありません。後で対処してください。まず、必要なクラスの種類を見つけます。 UMLクラスは抽象的な構成です。Javaクラスはこれまでに翻訳されない場合があります。UMLクラスは単なることわざです。「現在のところ、これらの意味のある機能を持つものが視点」。Javaクラスは、メモリを割り当てる方法と目的をマシンに指示する方法です。
UMLがあなたに必要なものを教えてくれたら、それからはじめて、これを実現する方法について考え始めることができます。
そして、はい、ドメイン駆動設計を使用します（同じタイトルの青い本はかなりいいです）。
（そして、私はアジャイルではないのでアジャイルの連中から非難されることは承知していますが、これについては取り扱わないでください。私たちはUMLについて話しているのです。この質問を気にしたくありません。
テーブルは必ずしもクラスの設計を促進するわけではありません。
たとえば、すべてのプログラムがDBに接続するわけではありません。テーブルがクラス設計を推進する場合、そのようなプログラムにはクラスがまったくないはずです。
このような一般的な質問については、一般的な答えしか出せません。
顧客が望むものを正確に提供するデータ駆動型アプリケーション（作成するのは非常に退屈です）があります。その場合、ドメイン（本当に必要な場合）はデータベーススキーマの完全な複製です。
また、アプリケーションがクラッシュした場合にデータベースが状態を保持する方法に過ぎないアプリケーションもあります。その場合、データベースの設計はそれほど重要ではなく（同時ユーザーの数が少ない場合）、データベースモデルはおそらくドメインモデルの複製になります。
適切なモデリング手法を使用してデータベースがモデル化され、適切なOOAD手法を使用してアプリケーションドメインがモデリングされるアプリケーションもあります。それらの違いは、ORMまたは手動マッパーを使用して解決できます。