ドメインモデルの描画に使用する概念のリストを作成したとしましょう。さらに、いくつかのシステムシーケンス図を作成したいくつかのユースケースがあります。
ドメインモデルを描くとき、どこから始めればよいのかわかりません。
私が物事を行う順序は無関係ですか？ユースケースの概念から設計するのがおそらく最善だと思います。これらは一般的に作業したいものであり、システム全体をうまく説明するのに役立つ他の種類の概念ではなく、多くの場合現在のプロジェクトでは必要ありません。ここで考慮していない他のアプローチはありますか？通常、これにどのようにアプローチしますか？
ありがとう
DDD かどうかにかかわらず、製品所有者にインタビューしてユビキタス言語 (UL) を決定することをお勧めします。あなたと製品所有者が同じ言語を話すような方法でコミュニケーションを確立することは、コミュニケーションを助けるだけでなく、共通の用語でプロジェクトについて議論できることは、ドメイン モデル自体を定義するのに役立ちます。
ですから、私の答えは基本的に、議論し、耳を傾け、学ぶことです。ソフトウェアはニーズに応えます。専門家の視点からモデルを理解することで、アプリケーションの強固な基盤が築かれます。
まず、すべての関係を含むクラス図を描き、アプリケーションの要件に応じて必要なクラスのみを実装します。
貧弱なアプローチ (属性とゲッターとセッター) を使用して物事をシンプルに保ち、同じステップでビジネス ロジックを記述するステップを回避できます。貧血モデルでは、ロジックは対応する Service クラスに入ります。そうすれば、後でユースケースを検討できます。
この方法を好まない人がいることは知っていますが、メンテナンスに役立ち、依存関係の問題を回避できます。
以下のむさぼり食ったエリジウムの質問への回答：
分析に関しては、ユースケース (What) から始めてクラス図 (How) に進むのが経験則のように思えます。個人的には、どのプロセス/オブジェクト間でメッセージを送信する必要があるかを知る必要があるため、後でシーケンス図 (いつ、誰が?) を作成します。
それを超えて、UML は単にシステム/プロジェクトをモデル化する方法であり、それ自体が方法論ではないというのが私の見解です (Merise、RAD、RUP、スクラムなどとは異なります)。図を完成させるのに十分な情報がある限り、誰かが図を書き始めるのを止めるものは何もありません。実際、各ダイアグラムは同じシステム/プロジェクトの異なる視点であるため、これらは同時に実行する必要があります。
つまり、全体として、分析をどのように行うかによって異なります。研究中に、コードを生成する前に最初から最後まで完全な分析を行う、厳格なウォーターフォール アプローチを教えられました。ただし、可能な限り短い時間で動作するアプリケーションを作成することが不可欠な場合があるため、実際には状況が異なる場合があります。
たとえば、私は最近、人々がフィクションを投稿できる Web サイトの作成に関する演習で、スクラムの方法論を紹介されました。時間的な制約と、何を達成すべきかについての明確なビジョンがあったため、ドメイン モデルを表す必要最小限のクラス図からすぐに始めました。次に、作成した一連のモック画面からユース ケースを推測しました。
記憶によると、クラスは Story、Chapter、User、Category でした。この最後のクラスは、より柔軟な Tag クラスを優先して段階的に廃止されました。ご想像のとおり、既存のプロジェクトの完全なクラス図は、ドメイン駆動設計と Java プログラミング言語の特殊性を適用するため、はるかに複雑になります。
このアプローチは、ずさんなものと見なされる可能性があります。ただし、このような Web サイトは、反復プロセスを使用して数週間で簡単に作成でき、それでも適切に設計されています。反復プロセスがウォーターフォール アプローチより優れている点は、要件を継続的に調整できることです。頻繁に要件が変更されることは現実です。なぜなら、人々はしばしば考えを変え、反復のたびに機能するアプリケーションを作成できる可能性があるため、いわばコースにとどまることができるからです。
もちろん、クライアントにプロジェクトを提示するときは、UML ダイアグラムといくつかのモック画面を使用した完全な分析が望ましいでしょう。そうすれば、彼らはあなたが何を提供しているかを把握できます。ここで UML の出番です。視覚的な規則のいくつかを説明したら、図を理解できるはずです。
最後に、クライアントが何を望んでいるかを判断しようとしている状況にある場合は、持参できるアンケートを徐々に作成することをお勧めします. アプリケーションに本当に必要なコンセプトや機能を判断するには、インタビューを行うしかありません。もう 1 つのヒントは、よく知らない話題に直面したときに Web で簡単な調査を行うことです。
あなたの例では、これは解剖学の基本を理解することです。とりわけ、これは、モデルに何を含める必要があり、どのような粒度を持たなければならないかを決定するのに役立ちます (臓器のどのグループを考慮する必要がありますか? どの程度の精度が必要ですか? 臓器のみをモデル化する必要がありますか、それともモデル化する必要がありますか?組織、細胞、化学組成などの構成要素?)。
始める場所は、論理的で快適だと感じるものなら何でもいいと思います。ユースケースから始めるのがおそらく最善です。ユースケースは明確な方向性と目標を提供し、YAGNIの状況を回避するのに役立ちます。強力なドメインモデルを開発しようとしていることを考えると、ドメインの全体像が重要であるため、それは実際には重要ではありません。
そのような状況での私の経験を共有したいと思います。私は通常、テストとコードを書くことから始めます。そして、エンドツーエンドのユースケースをカバーするようにしてください。これは私に問題について十分に公平な考えを与えてくれます、そして最後に私は私のクライアントにケースを示すことができる私と一緒に働いている何かを持っています。ほとんどの場合、後続のストーリーは前のストーリーの上に構築されますが、後続のストーリーには、私が思いついた前のモデルの変更が必要になることもあります。しかし、私はすでに十分なテストカバレッジを持っているので、これは私に影響を与えません。このようにして、現実の世界をマッピングするモデルではなく、現在の問題に適合するモデルを思いつきました。
簡潔な答え
ユース ケースを選び、コラボレーション図 (およびクラス図) を描いて、関連するドメイン オブジェクトを実現します。ユース ケースの目標を達成するために、参加しているオブジェクトのみに集中します。TDD テスト ケースを記述して期待値を設定し、期待値を満たすようにドメイン クラスを徐々にモデル化します。 TDDは、予想される動作を理解するのに非常に役立ち、よりクリーンなドメイン モデルを取得するのに役立ちます。TDD の期待に沿って、ドメインが徐々に進化することがわかります。
長い答え
DDD に関する私の個人的な経験は簡単ではありませんでした。そもそも必要な土台がなかったからです。私たちのチームには、さまざまな分野で多くの弱点がありました。要件が適切に把握されておらず、実際には役に立たなかった (関与していない) 顧客担当者しかいませんでした。適切なリリース計画がなく、開発者はオブジェクト指向の概念や最善の原則などを欠いていました。私たちが抱えていた主な問題は、ドメイン ロジックを理解するために多くの時間を費やしたことでした。多くのクラス図をスケッチしましたが、適切なドメイン モデルが得られなかったので、それをやめて何が問題なのかを突き止めました。問題は、ドメインのロジックを理解しようと努力しすぎて、コミュニケーションを取る代わりに思い込みをしてしまったことです。要件について。私たちはアプローチを変更することに決め、TDD を適用し、期待される動作を書き始め、TDD の期待に応えるようにドメイン モデルをコーディングしました。ドメインを理解していなかったために、TDD テスト ケースの作成に行き詰まることがありました。私たちはすぐに顧客担当者と話し、より多くの情報を得ようとしました。リリース戦略を変更しました。アジャイル手法を適用し、頻繁にリリースすることで、エンド ユーザーから実際のフィードバックを得ることができました。ただし、エンド ユーザーの期待が適切なレベルに設定されていることを確認する必要がありました。フィードバックに基づいてリファクタリングを行い、そのようにしてドメイン モデルが徐々に進化しました。その後、デザインパターンを適用して再利用性と保守性を向上させました。ここでの私のポイントは、DDD だけでは生き残れないということです。ドメインを包含するエコシステムを構築する必要があります。開発者は OOP の強力な概念を持ち、TDD と単体テストを理解する必要があります。DDD は、すべての OOP テクニックとプラクティスの上にあると言えます。
形式化されているかどうかにかかわらず、ビジネス要件から始めます。形式化されている場合は、ユースケース図を使用します。
たとえば、e コマース アプリのユース ケース図は次のとおりです: http://askuml.com/blog/e-commerce/
http://askuml.com/files/2010/07/e-commerce-use-case.jpg http://askuml.com/files/2010/07/e-commerce-use-case2b.jpg
これらのユース ケースから、ビジネス エンティティ (製品、製品のカテゴリ、ショッピング カートなど) を自然に推測できます。クラス図の作成が開始されます。
これは多くの方法論におけるベスト プラクティスですが、これも常識であり自然なことです。
