Oop 域模型中的专门化层次结构

我正在尝试制作管理系统的域模型。我在这个系统中有以下类型的人员：

employee
manager
top mananger

我决定定义一个用户，员工、经理和最高管理者将从中进行专业化。 现在，我不知道应该选择哪种专业化层次结构。 我无法在以下两种方式之间做出选择：

或

哪种可能更可取？为什么

作为一个长期的程序员，每次我尝试做一个领域模型时，我都必须反对这样一种想法，即尝试思考如何编写代码。据我所知，我不应该在域模型中考虑这些问题，而应该只考虑对象关系。我不必在这里考虑代码复制或任何此类细节，因此我无法真正选择任何选项

谢谢

编辑：

---

我会更明确一点：这是一个管理员工假期计划的程序。通过此程序，员工可以选择一年中的休假天数。然后，经理可能会批准或不批准每个员工的这几天，在这一天结束时，最高经理应该批准或不批准经理的决定。这是我的程序的所有用户都应该能够做到的。没有其他任务。

在现实生活中，经理也是员工。因此，这肯定只是一个不断专业化的链条：

User -> Employee -> Manager -> Top Manager 

编辑

这是一个用于管理 工人的休假计划

你们公司的经理有计划地休假吗？当然有。同样可以肯定的是，您不会构建一个单独的应用程序来管理它。所以你真正需要的是：

User -> Requester
     -> Approver

每个用户都是一个审批链中的请求者。您可能需要为首席执行官做出特殊安排。此外，一些用户将是一个或多个链中的审批人。最终批准人可能会根据请求者的级别而有所不同：CEO不想为批准看门人的假期安排而烦恼

您需要一些规则来强制执行谁可以成为任何给定请求者假期的审批人。除非你有一个非常扁平的组织，否则你会发现你有一个工人和经理的等级制度。例如，团队负责人或领班——在其他方面是工人而不是经理的个人——可能在链中。此外，你可能需要考虑组织的其他方面。例如，如果员工希望将休假延续到下一年，可能需要人力资源部的批准，通常对员工没有任何管理责任的人

编辑2

好的，我们是在模拟一组任意的规则，而不是一个现实的场景

让我看看。每个用户都属于一个类别，由以下任务定义：

员工可以申请休假 经理可以批准或拒绝休假请求 最高管理者可以接受或推翻批准或拒绝

---

管理者和高层管理者没有共同的行为。因此，第一个模型是正确的

这主要归结为如何定义术语的问题。最基本的问题是，在任何可能的情况下，管理者是否可以取代员工——如果不知道所模拟的工作场所的确切规则，就不可能以这种或那种方式来说明这一点

一个普遍的概念是，是的，至少在某一点上，在紧要关头，一个经理应该能够做他的任何下属的工作，至少比他低一级，而且很可能是两级或三级

---

另一方面，在一些有很多由工会推动的规则的地方，情况可能根本不是这样。即使一个人完全有能力胜任某项工作，规则也可能阻止他在该职位上顶替。在某些情况下，这是由认证要求引起的，例如，经理可能有资格从事工作，但所需的认证已失效，或者是由工会规则引起的，例如。，我的一个朋友曾经因为他把公司商店里的一个手电筒灯泡和电池带回了他的实验室而受到谴责，而没有让联合材料处理员来帮他做这件事。

我会把他们塑造成演员。它们不是系统的域，而是系统的用户。你会用“想要糖果的学童”、“想要烟草的学童家长”、“店员”等来模拟商店的库存系统吗？虽然只有门店经理参与者可以在没有收据的情况下进行退款，但在系统级别上，重要的是系统识别门店经理的密钥，软件中的权限令牌而不是参与者所扮演的角色

您描述的系统域是休假请求和用户帐户，一些用例意味着一些帐户有权对休假请求执行某些状态转换

不同的

---

将用户/经理/员工建模为参与者和角色的关键在于，您可以将重点放在建模需要放入系统的内容上，因为不必有参与者的层次结构——您开始在用例和系统实体级别使用抽象，而不是在参与者中使用抽象。思考“这在代码中是如何工作的”并不总是一个坏主意，至少在问“为什么要费心编写这种区别”时是这样。

我不认为是这样，因为员工的工作与经理完全不同。经理将管理员工，而员工将做脏活。经理从不干脏活。还是我错了？回到这个具体案例，我会更明确一点：这是一个管理员工休假计划的程序。通过此程序，员工可以选择一年中的休假天数。然后，经理可能会批准或不批准每个员工的休假日，最后，最高经理应该批准或否决经理的决定。虽然你强调了一个好的观点，但在计划规范中没有任何规定经理将休假，因此他们在该计划中不会休假。是的，我也认为他们没有任何共同点。我认为这里的情况是，一名员工所做的任务与一名经理所做的不同。两种类型的经理经理和高级经理实际上都做同样的事情，只有在不同的层次上：管理者证明或拒绝员工选择休假，而高层管理者可以改善或拒绝管理者的决定。