在设计域模型和类图时，我在理解要放入其中的内容时遇到一些麻烦。
我将举例说明我的意思：
我正在做假期调度程序，其中包含Administrator和End-Users。 Administrator执行了一些操作，例如在计划中注册End-Users，更改其优先权等。End-User可以选择他的假期等等。
我最初在域模型中定义了Administrator和End-User作为概念，后来又作为类图中的类。
在类图中，两个类最终都有一些方法，如
Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);
等
只有一段时间后，我意识到实际上Administrator和End-User都是演员，也许我的设计完全错了。我可以从域中定义其他类来执行它们，并让控制器处理用例（实际上，我决定为每个类执行一个用例）。例如，我可以使用UserDatabase.RegisterNewUser()和UserDatabase.UnregisterUser(int id);，而不是在Administrator类上使用这些方法。
我们的想法是尝试将整个假期调度程序视为一个“封闭程序”，它具有一系列功能，并且不会对身份验证等内容/内容/受保护等内容感到烦恼。我让外界看到的唯一公共事物就是它的控制者。
这是正确的做法吗？或者我完全错了？将Actors放在域模型/类图中通常是个坏主意吗？对此有什么好的经验法则？
我的讲师正在关注Applying UML and Patterns，我发现这很糟糕，所以我想知道在哪里可以查看有关此描述的演员模型情况的更多信息。
我对这一切仍然感到有些困惑，因为这种新方法与我之前所做的完全不同。
答案 0 :(得分：3)
我不会说你的设计，正如你推测的那样，是完全错误的，实际上Administrator和End-User是有效的域对象，应该在类图中以某种方式表示。仅仅因为您将这两个实体识别为参与者并不意味着它们应该被排除在域之外，请记住，您的域是您的范围，或“相关上下文”，即在您的域中起相关作用的一组有用对象解。
您可以从构成模型的基本对象开始，只需将其写下来，而无需进一步分析，如脑力冲击......
然后尝试建立这些对象之间的关系，如果找不到任何意味着你没有选择正确对象的关系，如果它们是同一个问题域的一部分，那么它们必须以某种方式相关。
过了一段时间，你会发现有些对象缺失，尝试尽可能地封装，并代表正确的抽象，设计模式可能会帮助你解决这个问题。
当每个可能的对象都用它的所有属性和方法表示时，你应该有一个完整但尚未完成的功能设计。
我知道你的思想中应该有很多理论，所以，在没有恐惧的情况下，我自己已经成功地多次使用这种方法。
最后获取UML Distilled
的副本问候，
答案 1 :(得分：2)
我认为你应该更多地了解域建模以及从用例到类图的过程。作为分类器的参与者可以是类图的一部分，但是用于分析和设计的类图是对您开发的系统进行建模，而actor是外部实体。当您使用用例和用例图时，目标是识别功能和非功能需求，因此定义要开发的系统范围和外部实体 - 角色或系统 - 与您正在开发的系统交互。在用例图中，您有时会发现一个表示系统边界的框，其中包含将在您的系统中实现的所有用例，但是演员是开箱即用的。在进行域建模时，您通常会完全忘记系统，因为您希望捕获域的工作方式。通常，特殊的图表和建模元素用于域建模。正如我所说，关键是要了解系统的使用域。分析和设计阶段的类图描述了您正在开发的系统，因此没有演员可以进入。