私は学校の課題を抱えており、人々の家に完全な食料品の袋を配達する特定の e コマース サイトのドメイン モデルを作成する必要があります。( http://www.linasmatkasse.se/ )
それは非常に基本的なことです。バッグを選び、アカウントを作成し（情報付き）、支払います。
私の質問は、モデルに正確に何を含めるべきですか(一般的に)? つまり、ドメインの行はどこで終わるのでしょうか? たとえば、配達とサプライヤーを含める必要がありますか? それらは技術的には Web サイト自体の一部ではなく、依然として役割を果たしています。
前もって感謝します！
いくつかのテーマ/主題を考えてみましょう。食料品の配達、衛星、ツバメの観察など、何でもかまいません。このテーマを「AAA」と名付けましょう
domain model for AAAは、 を表す「profi IT」という言葉ですmodel for AAA。それで全部です。
モデルに設定する AAA に固有のすべての要素は、ドメインに属します。なぜ古き良き言葉のテーマが使用されないのかわかりません。それは残念だ。しかし、その用語はすでに受け入れられています。
したがって、配送とサプライヤーはあなたのドメインにあります。また、食料品に属するより具体的な単語もあります。そしてバッグへ。そして、人々の家 - 住所、車の出入り - あなたのテーマに関連するすべてのもの。
ドメインは語彙を設定します。そして、これは非常に重要です。クライアントが使用する語彙を使用する必要があり、「テーマ」の「ドメイン」などの新しい単語を発明しないでください :-)
そして、最初にユース ケース図を定義し、後でステート マシン図、展開図、コンポーネント図、コミュニケーション図、シーケンス/アクティビティ/時間/相互作用の概要図を定義し、最後にクラス図、オブジェクト図、複合構造図を定義する必要があります。全部作る必要はありませんが、いくつかは必要です。
実際のエンティティをモデル化するすべてのエンティティは、ドメインの一部です。あなたの例では、配送とサプライヤーはドメイン モデルの一部である必要があります。基本的に、動作が定義されているエンティティはすべて、ドメインの一部としてモデル化する必要があります。多くの場合、ドメイン モデル コンポーネントは Web サイトの一部ではないように見えますが、これは実際には正常なことです。フロントエンドはドメイン モデルを表示する方法であり、ドメイン内のすべてを公開する必要はありません。私は通常、どのエンティティが現実世界のビジネス モデルの論理コンポーネントであるかを考えるのは簡単だと思います。冗長である、不要である、または別のエンティティ内にカプセル化できるとわかった場合にのみ、エンティティを削除します。
純粋な人間の操作を無視しないでください。それどころか。それらをここに置くと、それらのユース ケースのみがアクター (サブ) システムではなく、アクターとアクターを接続します。そして、それらを確認することは、システム全体をより適切に計画するのに非常に役立ちます。それらを無視すると、ユーザーにとって良いシステムを作ることはできません。IT システムは大規模なシステムの不可欠なコンポーネントであり、サポート、プロセス、情報の交換、分割、および依存関係を計画して、実際に大規模なシステムを作成しています。
私は、IT システムの境界外のことを何も知らないプログラマーとの問題を頻繁に抱えていました。そして、多くの場合、彼らにこれらの境界の外で考えさせることは不可能です. その結果、システムはユーザーの真のニーズにも盲目になります。つまり、ユーザーを嫌うソフトウェアの悲しいイメージがあります。
IT システムの外にあるエンティティから問題/ドメイン/テーマを検討し始め、最初に IT システムを多くのブロックの 1 つにすぎないと見なす図を作成することは非常に役立ちます。