ドメイン駆動設計を使用するときに UML クラス図を編成する方法について、誰かが良いサンプルを持っているかどうか知りたいです。
リポジトリとサービスを使用して適切なエンティティを作成する方法が本当にわかりません。
ドメイン駆動設計を使用するときに UML クラス図を編成する方法について、誰かが良いサンプルを持っているかどうか知りたいです。
リポジトリとサービスを使用して適切なエンティティを作成する方法が本当にわかりません。
私が最終的に DDD 用に作成する UML ダイアグラムは、通常、手書きで非形式的であり、すべてのガイドラインに厳密に従っているわけではありません。UML の観点からは、エンティティ、リポジトリ、およびサービスはすべて単なるクラスです。わかりやすくするために、クラスをステレオタイプでマークすることができます。
さらに、クラス図だけにあまり重点を置きません。多くの場合、行動の観点からモデルを検討する方が有益です。この場合、シーケンス図が役立ちますが、すぐに技術的になりすぎる可能性があります。クラス ダイアグラムは集合体とエンティティを識別するのに役立ちますが、動詞ではなく名詞を強調しすぎて誤解を招く可能性もあります。
DDD のもう 1 つの重要なタイプのダイアグラムは、境界付けられたコンテキストのクラス ダイアグラムとして表示できるコンテキスト マップです。コンテキスト マップを表現するための明示的な UML プラクティスは存在しないため、非公式のアプローチが最も効果的です。
全体として、私にとってうまくいったのは、摩擦が少なく、式典が少なく、非公式です. ボックスを使用して概念を表し、それらの間の線を使用して関係を表します。それを超えるものは確かに役に立ちますが、他の側面を犠牲にするべきではありません.
また、図の目的も理解する必要があります。それらは設計とモデリングのプロセスを容易にするためのものですか? それらはドキュメンテーション用ですか?会話を弾ませるには?コミュニケーションのため?これらの理由にはそれぞれ、特定の制約がある場合があります。
私の提案:各DDDビルディングブロック(例:<>、<、<>など)のステレオタイプを構築し、このステレオタイプのいずれかで各クラスに署名し、「使用」接続のみを使用します...(集約のみの複合)