ドメイン モデルを実行する場合、どこから始めればよいでしょうか?

Question

ドメイン モデルを描くために使用する概念のリストを作成したとします。さらに、いくつかのユースケースがあり、そこからいくつかのシステム シーケンス図を作成しました。

ドメイン モデルを描くとき、​​どこから始めればよいのかわかりません。

1. 私が信じているシステムとしてモデルを設計します。つまり、人体をモデリングしている場合、心臓、脳、腸、胃、目、頭などのクラス概念を追加することから始めます。
2. ユースケースを実行するために必要なものを設計することから始めます。つまり、人間の体に何かを飲み込ませることに関するユースケースがある場合、最初に口、喉、胃、腸などのクラス概念を描画します。

物事を行う順序は関係ありませんか？おそらく、ユース ケースの概念から設計を試みるのが最善だと思います。ユース ケースの概念は、一般的に作業したいものであり、システム全体をうまく説明するのに役立つものの、多くの場合、他の種類の概念ではないからです。現在のプロジェクトには必要さえありません。ここで考慮していない他のアプローチはありますか?通常、これにどのようにアプローチしますか?

ありがとう

Answer 1

私なら、すべての関係を含むクラス図を描くことから始め、アプリケーションの要件に従って必要なクラスのみを実装します。

貧弱なアプローチ (属性にゲッターとセッターを加えたもの) を使用すると、物事をシンプルにし、同じステップでビジネス ロジックを記述するステップを避けることができます。貧血モデルの場合、ロジックは対応する Service クラスに入ります。そうすることで、後でユースケースを検討することができます。

この方法を好まない人もいるとは思いますが、メンテナンスに役立ち、依存関係の問題を回避できます。

以下の貪欲なエリジウムの質問に対する答え:

分析に関しては、ユースケース (What) から始めて、クラス図 (How) に進むのが良い経験則のように思えます。個人的には、どのプロセス/オブジェクト間でメッセージを送信する必要があるかを知る必要があるため、その後シーケンス図 (いつ、誰が?) を作成します。

それ以上に私の見解は、UML はシステム/プロジェクトをモデル化する単なる方法であり、それ自体が方法論ではないということです (Merise、RAD、RUP、Scrum などとは異なります)。図を完成させるのに十分な情報があれば、どんな図でも作成を始めるのを妨げるものはありません。実際、各図は同じシステム/プロジェクトの異なる視点であるため、これらは同時に実行する必要があります。

つまり、全体的には、分析をどのように行うかによって決まります。私は研究中に、コードを作成する前に最初から最後まで完全な分析を行う厳格なウォーターフォール アプローチを教えられました。ただし、実際には動作するアプリケーションをできるだけ短い時間で作成することが不可欠であるため、状況が異なる場合があります。

たとえば、私は最近、小説を投稿できる Web サイトの作成に関する演習でスクラム方法論を紹介されました。時間の制約があり、何を達成すべきかについての明確なビジョンがあったため、私たちはすぐに必要なクラス図を作成して、 ドメインモデル. 。次に、私たちが作成した一連の模擬画面からユースケースが推定されました。

記憶によれば、クラスはストーリー、チャプター、ユーザー、カテゴリーでした。この最後のクラスは、より柔軟な Tag クラスを優先して段階的に廃止されました。ご想像のとおり、既存のプロジェクトの完全なクラス図は、ドメイン駆動設計と Java プログラミング言語の特性を適用するため、さらに複雑になります。

このアプローチはずさんだとみなされる可能性があります。ただし、このような Web サイトは、反復的なプロセスを使用して数週間で簡単に作成でき、依然として優れたデザインを維持できます。反復プロセスがウォーターフォール アプローチに比べて優れている点は、進行中に要件を継続的に調整できることです。頻繁に要件が変更されるのは現実です。人々は頻繁に考えを変えるものであり、反復のたびに機能するアプリケーションを作成できる可能性があるため、いわばコースに沿って進むことができます。

もちろん、クライアントにプロジェクトを提示するときは、クライアントが何を提供しているのか理解できるように、UML 図といくつかの模擬画面を使用した完全な分析が望ましいでしょう。ここでUMLが登場します。いくつかの視覚的な規則を説明すれば、人は図を理解できるはずです。

最後に、クライアントが何を望んでいるのかを見極める必要がある場合は、持参できるアンケートを少しずつ増やしていくとよいでしょう。人にインタビューすることは、アプリケーションに本当に必要なコンセプト/機能を判断できる唯一の方法であり、特定の側面を明確にするために戻ることを期待する必要があります。もう 1 つのヒントは、馴染みのない主題に直面したときに、ウェブで簡単に調べてみることです。

あなたの例では、これは解剖学の基礎を学ぶことになります。とりわけ、これは、モデルに何を含めるべきか、どのような粒度を持つべきかを決定するのに役立ちます (どの臓器のグループを考慮すべきか?)どれくらいの精度が必要ですか?臓器のみをモデル化する必要があるのか​​、それとも組織、細胞、化学組成などの構成要素に分解する必要があるのか​​。?)。

Answer 2

かどうかDDD、またはない、私は、製品の所有者（複数可）のインタビューでユビキタス言語（UL）の決定に推薦します。あなたとプロダクトオーナーが通信だけでなく側近同じ言語を話す必要があります方法で通信を確立するが、一般的な用語でプロジェクトを議論できることはドメインモデル自体の定義を支援する傾向があります。

だから、私の答えは、議論聞き、そして学ぶことは基本的です。ソフトウェアは必要性を提供しています。専門家の視点からモデルを理解することは、アプリケーションのための強固な基礎を築くだろう。

Answer 3

私が開始する場所は論理的かつ快適に感じるものは何でもあることだと思います。それは、彼らはあなたに明確な方向性や目標を与え、そしてヘルプあなたはYAGNIの状況を避けるよう、ユースケースから始めるのがおそらく最善です。ドメインの全体像が重要であるとして、それは、本当に問題、あなたは強力なドメインモデルを開発しようとしなければならないということではないはずですが与えられます。

Answer 4

私は状況のようなタイプのために私の経験を共有したいと思います。私は通常、テストやコードを書くことで始まります。そして、ユースケースを終了する一方の端をカバーしよう。これは私の問題について、公正に十分なアイデアを提供し、最後にまた、私は私のクライアントにケースを表示することができます私と一緒に働いて何かを持っています。時間以降の話のほとんどは、以前のものの上に構築、また、その後の物語は私が思いついた以前のモデルの変更を必要とすることを私に起こります。私はすでに良いテストカバレッジを持っているとして、しかし、これは私に影響を与えません。このように、私は、現在の問題のために適合モデルではなく、現実の世界をマップモデルを思い付います。

Answer 5

あなたは正式にかないことができ、ビジネス要件で始まります。正式な場合は、ユースケース図を使用することになります。

ここで例えば、

は、電子商取引アプリケーションのためのユースケース図です。 http://askuml.com/blog/e-commerce/する

http://askuml.com/files/2010 /07/e-commerce-use-case.jpgする http://askuml.com/files/2010/07/ Eコマース利用-case2b.jpgする

これらのユースケースから、あなたは自然にビジネスエンティティを推測することができます。クラス図を準備するために開始されている...製品、製品のカテゴリ、買い物かごを、

これは、多くの方法論におけるベストプラクティスですが、これも常識と自然です。

Answer 6

短い答え

ユースケースを選択し、コラボレーション図 (およびクラス図) を描いて、関連するドメイン オブジェクトを実現します。ユースケースの目標を達成するために、参加するオブジェクトのみに集中してください。TDD テスト ケースを作成して期待値を設定し、期待値を満たすようにドメイン クラスを徐々にモデル化します。 TDD 予想される動作を理解するのに非常に役立ち、よりクリーンなドメイン モデルを取得するのに役立ちます。TDD の期待に沿ってドメインが徐々に進化しているのがわかります。

長い答え

DDD に関する私の個人的な経験は簡単なものではありませんでした。それは、そもそも必要な基礎がなかったからです。私たちのチームにはさまざまな分野で多くの弱点がありました。要件が適切に把握されておらず、あまり役に立たない (関与していない) 顧客担当者しかいませんでした。私たちには適切なリリース計画がなく、開発者にはオブジェクト指向の概念や最良の原則などが欠如していました。私たちが抱えていた主な問題は、ドメイン ロジックを理解するのに非常に多くの時間を費やしたことでした。私たちは多くのクラス図をスケッチしましたが、ドメイン モデルを正しく理解できなかったので、それをやめて、何が問題だったのかを見つけました。問題は、ドメインのロジックを理解しようと努めすぎて、コミュニケーションをとる代わりに、 仮定 要件について。私たちはアプローチを変更することを決定し、TDD を適用し、予想される動作の記述を開始し、TDD の期待を満たすようにドメイン モデルをコーディングしました。ドメインを理解していないために、TDD テスト ケースの作成に行き詰まることがありました。私たちはすぐに顧客担当者に相談し、さらに意見を求めました。私たちはリリース戦略を変更しました。アジャイル手法を適用し、頻繁にリリースすることで、エンド ユーザーから実際のフィードバックを得ることができました。ただし、エンド ユーザーの期待が適切なレベルに設定されていることを確認するために必要でした。フィードバックに基づいてリファクタリングを行い、そのようにしてドメイン モデルは徐々に進化しました。その後、デザインパターンを適用して再利用性と保守性を向上させました。ここで私が言いたいのは、DDD だけでは生き残ることはできず、ドメインを包含するエコシステムを構築する必要があり、開発者は強力な OOP 概念を持ち、TDD と単体テストを高く評価する必要があるということです。DDD はすべての OOP テクニックとプラクティスの頂点に位置すると思います。