問題タブ [modeling]

私はこの議論にかなり慣れていませんが、「無知」に聞こえるリスクを冒してでも、この質問をしなければなりません。なぜ今、「DDD」が強調されているのでしょうか。「DDD」を調べれば調べるほど、アプリケーションが複雑になっているようです。一方、データベースを使用してドメインをモデル化すると、レイヤー全体でアプリケーションの一貫性を保つことができます。次に、SubSonic や L2S などの DAL ヘルパーを使用して、そのモデルに簡単にアクセスできます。これの何が悪いの？エンタープライズ アプリケーションでも？

実証済みの方法があるのに、ドメインをモデル化する新しい方法を作成しようとするのはなぜでしょうか?

ここで純粋主義者からの連絡をお待ちしています。

「グリーン 特大 Tシャツ」などの商品を販売するオンラインストアを構築しています。つまり、同じシャツでもサイズや色が異なる場合があり、組み合わせによって売り切れたり、組み合わせによって価格が異なる場合があります。

私の質問は、Rails アプリケーションでこれらの製品をどのようにモデル化する必要があるか (または、どのアプリケーションでどのようにモデル化するか) です。

私の現在の考えは次のとおりです。

したがって、各製品には 1 つ以上の特性 (「色」、「サイズ」など) があり、各特性には 1 つ以上のバリエーション (「赤」、「青」など) があります。

この方法の問題点は、価格と在庫をどこに保管するかということです。つまり、特定の製品の価格と在庫は、その特性が取るバリアントによって決定されます。（緑は赤よりも高価である可能性があり、大型は在庫がない可能性があるなど）.

私が考えた 1 つの考えは、製品に「base_price」を与え、バリエーションでそれを変更できるようにすることでしたが、これは非常に複雑に思えます (そしてうまくいかないかもしれません)。

これは通常、クラスを設計する方法ですか? 1 クラス = 1 テーブル。別のテーブルへの外部キーを含むテーブルはどうですか?

次のものがあるとします。

テーブルごとにクラスを作成することをお勧めしますか? もしそうなら、そのようなクラスをオームなしでデータベースにロード/保存するためのベストプラクティスは何ですか? 簡単なコード例は本当に役に立ちます

まず、この質問のフィードバックの性質について申し訳ありません。できる限り一般化して、他の人も同様に得られるようにしていますが、この設計についてフィードバックをくれる人が実際にはいないので、皆さんが私を助けてくれることを願っています.

そうは言っても、データベースでさまざまなユーザータイプをモデル化するつもりはありません。ただし、ユーザータイプの資格情報を共有したいと思います。この問題は基本的に継承に関するものであり、RDB ではうまく機能しません。

しかし、私はこのデザインを思いつきました: DB design http://img48.imageshack.us/img48/9196/dbdesign.png

..しかし、それで満足するべきかどうかはわかりません。私が気に入らないのは、そこに含まれるビジネス契約の量です。まず第一に、特定の資格情報に属するユーザー タイプがわかりません。つまり、N 個のテーブルを検索する必要がある可能性があります。N は、取得したユーザー タイプの数です。したがって、ユーザーのタイプをそのユーザーのロールに関連付けることを考えました。したがって、資格情報 A を持つユーザーが「UserType1」と「UserType2」のロールを持っている場合、UserType1 と彼または彼女を表す UserType2 テーブル。-そして、これらの「ビジネスロジック」の制約が好きかどうかはわかりません.. :)

代替設計と同様に、この設計に関するフィードバックは非常に高く評価されます。

前もって感謝します

私のオンライン ストアでは、各注文に配送先住所と請求先住所が関連付けられています (もちろん、同じ住所でもかまいません)。これは、これをモデル化する最初の試みです。

これはかなりうまく機能しますが、フォーム ヘルパーが機能しなくなりました。つまり、form_forのような名前のフィールドのみを生成するaddress[zipcode]ため、手動でハックして および を取得する必要がbilling_address[zipcode]ありshipping_address[zipcode]ます。

単一テーブルの継承を使用してandにサブクラスAddress化できると思いますが、これは少しハックに思えます (そして、Customer <--> Address をモデル化するための最良の方法のいくつかの良い答えと矛盾します)。ShippingAddressBillingAddress

私たちのクライアントは、ソフトウェア要件を収集するための Web ベースのリッチ インターネット アプリケーションを構築することを望んでいます。基本的には、利害関係者から要件を取得するための特定のプロセスに従う Web ベースのケース ツールです。私はプロジェクト マネージャーで、まだプロジェクトの初期段階にあります。

クライアントと開発者の両方にとってツールの要件を明確にするために、形式的な方法を使用することを考えていました。正式な方法とは、何らかの形のモデリング、おそらく数学に基づくものを意味します。Z ( http://en.wikipedia.org/wiki/Z_notation )、ステート マシン、UML 2.0 (おそらくOCLなどの拡張機能を使用)、ペトリ ネット、およびいくつかのコーディングについて読んだことがあり、検討していることもあります。契約や前後の条件などのレベルのもの。他に考慮すべきことはありますか？

開発者は経験豊富ですが、使用する形式によっては、数学を学ぶ必要がある場合があります。

このプロジェクトで形式的な方法を使用する価値があるかどうか、もしそうならどの程度の価値があるかを判断しようとしています。私は「場合による」ことを知っているので、私にとって最も役立つ答えは、はい/いいえとそれを裏付ける議論です。

あなたがこのプロジェクトに参加した場合、正式な方法を使用しますか?

売り手、買い手、本という 3 つのエンティティ (クラス) を持つ書店を構築します。データベースを次のように設計しました。
- 買い手と売り手の両方が、それぞれ 1 冊以上の本を売買できます。
- 購入者が本を販売したい場合、販売者アカウントが必要です。
- 買い手は自分の価格を提示し、売り手は最高の買い手に売りたいので、これらのすべての情報を保存する必要があります。

これはうまくいくと思いますが、価格オファーで作業するにはどうすればよいですか?
はい、プロセスクラスにオファーを追加できるので、気が変わってこのモデルが登場しました: (長い説明で申し訳ありません)

*Offer* フィールドが *process* クラスに追加されます。 ______ ______ __________ ________ |売り手| | | 本 | |プロセス | | | バイヤー | -------- -------- ----------- ---------- | | SID* | | | bID* | | | pID* | | | byID* | | | 名前 | | | XXX | --> | SID | | | オファー | | | 日付 &..| ----------- (*) は主キーを示します

初めてなので、データベースの設計に完全に混乱しています。これでシステムのニーズを満たすことができますか? いいえの場合、どのように機能させることができますか? はいの場合、より良いデザインはありますか？

どんな提案でも大歓迎です、事前に感謝します:)

更新- ここで最良の回答を選択することはできません。すべて役に立ちました。たくさんの人に感謝します。よろしくお願いします^o^

私はクラス図をモデル化していますが、この問題に完全に悩まされています。

私の新しいWebアプリケーションには、ユーザーが変更できる「カード」（主題に関するエントリ）があります。しかし、ウィキとは異なり、カードが異なればデータも異なります。また、ウィキとは異なり、カードはデータベース内で明示的に他のカードと相互に関連しています。ダミーの例を使用して、最初にどのように設計したかを示します。

エレガントで清潔ですが、間違っています。このアプローチを使用すると、美術館は絵画自体ではなく、絵画バージョンに関連付けられます。私の頭から離れた最初の解決策はこれでした：

このアプローチはにおいがします。CardInfoVersionの下のクラス階層は巨大であるため、UMLモデルは読み取り不能になり、CardクラスはCardInfoVersionサブクラスへのORM参照で埋められます。それから私はこれを思いついた：

これもにおいがします。実際、バージョンが消えてから、これはすべて台無しになっています。また、管理者はカードに提案された変更を検証する必要があります。

私はこの問題を解決する方法を本当に知りません。注意：CardInfoVersionサブクラスが相互に関連していなければ、元の設計で問題ありません。

助けてください！

これは漠然と次のように関連しています:

アプリケーションまたはモデル (データベース) を最初に設計する必要がありますか?

最初にデータベースから UI まで設計するか、それとも逆に設計するか?

しかし、私の質問はモデリングとアーティファクトに関するものであり、デザインの正しい方法に関するものではありません。機能 (ユース ケース)、画面、データベース要素 (特にテーブルと列) の間のリンクを最も明確に表現するのに最適な設計成果物を見つけようとしています。UML は非常にコード中心です。データベース モデルは非常にデータベース中心です。そして画面デザインはUI中心！

これが取引です...私のチームは製品の最初のリリースに取り組んでいます。ユースケースを使用し、次に画面設計を行い、データベース設計はこの 2 つから多少分離されました。バグの重大な領域は、ユースケースとそれに付随する画面およびデータベース間のトレーサビリティの欠如でした。私たちの製品では、ユースケースとデータベース要素の間に非常に高度な重複があります。多くのユース ケースは、データベース インフラストラクチャの 75% 以上に関係しています。そのため、データベースの設計領域で競合が多く、データベースの小さな変更が下位レベルのビジネス ロジックを混乱させるのは簡単です。

次のリリースでは、開発者と DBA に、各機能がデータベースのどの部分に影響を与えるかについて明確な洞察を得てもらいたいと思っています。ユースケース/画面設計のアプローチはうまく機能したので、そのままにしておきます...秘訣は、各ユースケースと画面をデータベースモデルにリンクすることです。これにより、関係が非常に明確になり、忘れにくくなります。

小規模なプロジェクト (私たちは 10 人しかいませんが、3 人以下のチームで作業することがよくあります) では、設計のこの部分を示すために独自のカスタム図を作成しました。実際のコードや SQL へのリンクなしで Visio で行われる、画面、UML、およびデータベース テーブルの一種の融合。最新の状態に保つには非常に手作業が必要であり、データベース モデリング ツールのようにコードを自動生成しないため、大規模なチームで機能するかどうかはわかりません。

推奨事項はありますか？これに対して一般的に受け入れられているメカニズムはありますか？

参考までに - 私たちはかなりのウォーターフォールであり、それはすぐに変わることはありません. そして、私たちはアーティファクトが大好きです... 「アジャイルへの切り替え」と言うのは、私たちのグループにとって実行可能な解決策ではありません。

POJO のプロパティを同期するためのフレームワークはありますか? たとえば、反復的でエラーが発生しやすい値と (特に) コレクションで、プロパティの変更、要素の追加、およびリスナーの削除を登録する必要がないことをfoo.text = bar.text + baz.text(高レベルの宣言形式で) 表現したいと考えています。foo.y = (max(bars, y)).y