俳優をドメインモデル/class-diagramに入れるべきですか？

Question

ドメインモデルとクラスダイアグラムの両方を設計するとき、私はそれらに何を入れるべきかを理解するのに苦労しています。

私が意味することの例を挙げてください：

私はバケーションスケジューラプログラムを行っています Administrator と End-Users. 。 Administrator 登録のようなことをいくつかします End-Users プログラムでは、彼らのプレ・プレビレジなどを変更します。 End-User 彼の休暇の日などを選ぶことができます。

最初に定義しました Administrator と End-User ドメインモデルの概念として、そして後にクラスディアグラムのクラスとして。クラスディアグラムでは、両方のクラスが最終的に次のようないくつかの方法を持っていました

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

等

しばらくして初めて、私は実際に両方とも気付きました Administrator と End-User 俳優であり、多分私はこのデザインをまったく間違っています。管理者とエンドユーザーのクラスに、ユースケースの要求を行う方法を入力する代わりに、ドメインから他のクラスを定義してそれらを実行することができ、コントローラーにユースケースを処理させることができます（実際、それぞれのために1つを行うことにしました使用事例）。私は持っていることができます UserDatabase.RegisterNewUser() と UserDatabase.UnregisterUser(int id);, 、たとえば、これらの方法を持っている代わりに Administrator クラス。

アイデアは、休暇のスケジュール全体を、一連の機能を備えており、認証などのものを気にしない「クローズドプログラム」と考えようとすることです。私が外の世界に見せてくれたものは、そのコントローラーです。

これは正しいアプローチですか？それとも私はこれを完全に間違えていますか？俳優をドメインモデル/クラスダイアグラムに入れることは、一般的に悪い考えですか？これに対する良い経験則は何ですか？

私の講師はフォローしています UMLとパターンの適用, 、私はひどいと思うので、この説明されている俳優モデルの状況に関する詳細情報をどこで調べることができるかを知りたいです。

この新しいアプローチは、私が以前にやったこととは根本的に異なるため、私はまだこのすべてについて少し混乱しています。

Answer 1

あなたが推測するように、あなたのデザインは完全に間違っているとは言いません。実際、管理者とエンドユーザーは、クラス図で何らかの形で表現する必要がある有効なドメインオブジェクトです。これらの2つのエンティティをアクターとして識別するからといって、ドメインから除外されるべきではありません。ドメインは範囲、つまり「関連するコンテキスト」、つまり、関連する役割を果たす有用なオブジェクトのセットであることを忘れないでください。解決。

あなたは、あなたのモデルを構成する基本的なオブジェクトから始めて、ブレインストーミングのようなさらなる分析なしでそれらを書き留めるだけです...

• 休暇
• 位置
• 旅行代理店
• スケジュール
• ユーザー
• 予約
• 予約サービス（これは休暇の予約にアクセスするためのインターフェイスになる可能性があります）

次に、それらのオブジェクト間の関係を確立してみてください。適切なオブジェクトを選択していないことを意味する関係を見つけることができない場合、それらが同じ問題ドメインの一部である場合、それらは何らかの形で関連している必要があります。

しばらくすると、オブジェクトが欠落していることがわかり、可能な限りカプセル化しようとし、正しい抽象化を表して、設計パターンがそれを助けるかもしれません。

可能なすべてのオブジェクトがそのすべてのプロパティとメソッドで表されている場合、まだ完成していないものの、機能的な設計を完全に持っている必要があります。

私はあなたがあなたの心の中に多くの理論を持っているべきだと知っているので、恐れることなく、私自身は仕事で何度もこのアプローチをうまく使ってきました。

最後に、のコピーを取得します uml蒸留

よろしく、

Answer 2

ドメインモデリングと、ユースケースからクラス図に到達するプロセスについてさらに学ぶべきだと思います。分類器としてのアクターはクラス図の一部になる可能性がありますが、分析と設計に使用されるクラス図では、開発するシステムのモデリングであり、アクターは外部エンティティです。ユースケースとユースケース図を使用している場合、目標は機能的および非機能的なリキュレメントを特定することです。したがって、開発するシステムと外部エンティティ（役割またはシステム）が開発しているシステムと対話するシステムの範囲を定義します。ユースケース図では、システムで実現されるすべてのユースケースを含むシステムの境界を表すボックスを見つけることができますが、アクターは箱から出ていません。ドメインモデリングの場合、ドメインの仕組みをキャプチャしたいため、通常、システムを完全に忘れます。多くの場合、ドメインモデリングには特別な図とモデリング要素が使用されます。私が言ったように、ポイントは、システムが使用されるドメインを理解することです。分析と設計段階のクラス図は、開発しているシステムを説明しているため、俳優が内部にいることはありません。