在设计域模型和类图时，我在理解要放入其中的内容时遇到了一些困难。
我举一个例子来说明我的意思:
我正在做一个假期调度程序，它有一个Administrator 和End-Users。 Administrator 会做一些事情，比如在程序中注册 End-Users，更改他们的特权等。End-User 可以选择他的假期等
我最初将 Administrator 和 End-User 定义为域模型中的概念，后来定义为类图中的类。
在类图中，两个类最终都有几个方法，例如
Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);
等等
一段时间后我才意识到实际上Administrator 和End-User 都是参与者，也许我的设计完全错误。我可以定义域中的其他类来完成它们，并让 Controller 处理用例，而不是用方法填充管理员和最终用户类来执行我的用例请求(实际上，我决定为每个类做一个用例)。例如，我可以有一个 UserDatabase.RegisterNewUser() 和 UserDatabase.UnregisterUser(int id);，而不是在 Administrator 类。
我们的想法是尝试将整个假期安排程序视为一个“封闭程序”，它具有一组功能并且不会打扰诸如身份验证之类的事情，这应该是内部的/ protected ，因为我唯一能让外界看到的公共(public)事物就是它的 Controller 。
这是正确的方法吗？还是我完全错了？将 Actors 放入域模型/类图中通常是个坏主意吗？对此有哪些好的经验法则？
我的讲师正在关注 Applying UML and Patterns ，我觉得这很糟糕，所以我想知道在哪里可以找到有关这种描述的 Actor 模型情况的更多信息。
我对所有这些仍然有点困惑，因为这种新方法与我以前做过的任何事情都截然不同。
最佳答案
我不会像您推测的那样说您的设计是完全错误的，事实上管理员和最终用户是有效的域对象，应该以某种方式在类图中表示。仅仅因为您将这两个实体标识为参与者并不意味着它们应该被排除在域之外，请记住，您的域是您的范围或“相关上下文”，即在您的领域中扮演相关角色的一组有用对象解决方案。
您可以从构成模型的基本对象开始，只需将它们写下来，无需进一步分析，例如头脑 Storm ……
- 假期
- 地点
- 旅行社
- 时间表
- 用户
- 预订
- 预订服务(这可以是访问假期预订内容的接口(interface))
然后尝试建立这些对象之间的关系，如果您找不到任何关系，则意味着您没有选择正确的对象，如果它们属于同一问题域，那么它们必须以某种方式相关。
一段时间后，您会发现缺少对象，尝试尽可能封装并表示正确的抽象，设计模式可能会帮助您解决这个问题。
当每个可能的对象都用它的所有属性和方法表示时，您应该有一个完整的(尽管尚未完成)功能设计。
我知道你脑子里应该有很多理论，所以开始吧，不要害怕，我自己在工作中多次成功地使用了这种方法。
终于得到一份UML Distilled
问候，
关于c# - 我应该把 Actor 放在领域模型/类图中吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2978886/