领域模型中的专业化层次结构
我正在尝试制作管理系统的域模型。我在这个系统中有以下几种人：
employee
manager
top mananger
我决定定义一个 User，其中 Employee、Manager 和 Top Manager 将专门化。 现在，我不知道我应该选择什么样的专业化层次。 我无法在以下方式之间做出决定：
或
哪个可能更可取，为什么？
作为一名长期编码员，每次我尝试制作领域模型时，我都必须与尝试思考如何编码的想法作斗争。根据我的理解，我不应该在领域模型中考虑这些问题，而应该只在对象关系中考虑这些问题。我不必在这里考虑代码重复或任何此类细节，因此我无法真正选择任何一个选项。
谢谢
编辑：
我会更明确一点：这是一个管理员工假期计划的程序。通过此程序，员工可以选择一年中的休假天数。然后，经理可能会批准或不批准每位员工的这些日子，并且最终，最高管理者应该批准或不批准经理的决定。这是我的程序的所有用户都应该能够做到的。没有其他任务。
I'm trying to make the domain model of a management system. I have the following kind of people in this system:
employee
manager
top mananger
I decided to define an User, from where Employee, Manager and Top Manager will specialize from.
Now, I don't know what kind of specialization hierarchy I should choose from.
I can't decide between the following ways:
or
Which might be preferable and why?
As a long time coder, every time I try to do a domain-model, I have to fight against the idea of trying to think in how I'm going to code this. From what I've understood, I should not think about those matters in the domain-model, only in object relationships. I don't have to think of code duplication or any of these kind of details here, so I can't really pick any of the options over the other.
Thanks
EDIT:
I'll be a bit more explicit: This is a program to manage worker's vacations plans. With this program, a employee can choose the set of vacations days for the year. Then the manager might approve or not those days for each one of the employees and at the end of the day the top manager should approve or disapprove the manager's decisions. This is all the users of my program are supposed to be able to do. There are no other tasks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这主要归结为如何定义术语的问题。基本问题是，在任何可能的情况下，经理是否可以取代员工——并且在不了解所建模工作场所的精确规则的情况下，不可能对此做出这样或那样的说法。
一个普遍的观念是，是的，至少在某种程度上，在紧要关头，经理应该能够完成他任何下属的工作（至少比下一级，很可能是两到三级）。
另一方面，在一些制定了许多工会驱动规则的地方，情况可能根本不是这样。即使一个人完全有能力胜任某项工作，规则也可能根本阻止他替代该职位。在某些情况下，这源于认证要求等（例如，经理可能有资格从事这项工作，但所需的认证已经失效）或工会规则之类的事情（例如，我的一位朋友曾经因为他将手电筒灯泡和电池从公司商店带回实验室，而不是让工会材料处理员为他做这件事）。
This mostly comes down to a question of how you define your terms. The basic question is whether a manager can be substituted for an employee under any possible circumstances -- and without knowing the precise rules of the workplace being modeled, it's impossible to say one way or the other about that.
One general notion is that yes, at least up to a certain point, in a pinch a manager should be able to do the job of any of his subordinates (at least one level below, and quite possibly two or three).
On the other hand, in some places with lots of union-driven rules in place, that may not be the case at all. Even if a person is entirely capable of doing a job, rules may prevent him from substituting in that position at all. In some cases this arises from certification requirements and such (e.g., the manager may have one been qualified to do the work, but the required certification has lapsed) or from things like union rules (e.g., a friend of mine who was once reprimanded because he carried a flashlight bulb and battery from the company store back to his lab instead of getting a union materials handler to do that for him).
在现实生活中，经理也是员工。所以这肯定只是一个不断增加的专业化链条：
编辑
在您的公司中，经理会按计划休假吗？当然他们会这样做。同样可以肯定的是，您不会构建一个单独的应用程序来管理它。所以您真正需要的是：
每个用户都将是一个请求者（您可能需要对 CEO 进行特殊安排）。此外，一些用户将是一个或多个链中的审批者，这可能会根据请求者的级别而有所不同：CEO 不会愿意打扰。 您将需要一些规则来强制执行任何特定请求者
假期的批准者，除非您有一个非常扁平的组织，否则您会发现您有一个工人和经理的等级制度。 、团队领导或领班 - 在其他方面是“工人”而不是“经理”的个人 - 可能也在链条中，例如，如果员工希望承担的话，您可能需要考虑组织的其他方面。留到下一年可能需要人力资源部门的批准，该部门通常对员工没有任何管理责任。
编辑 2
好的，我们正在对任意一组规则而不是现实场景进行建模。
让我们来看看。每个用户都属于由以下任务定义的单一类别：
经理和高层管理人员没有共同的行为。因此，第一个模型是正确的。
In real life, Managers are Employees too. So this is surely just a chain of increasing specialisation:
edit
In you company do Managers take planned vacation? Surely they do. And equally surely you are not going to build a separate application to manage that. So what you really need is this:
Each User will be a Requester in one approval chain. (You may need special arrangements for the CEO). In addition some Users will be Approvers in one or more chains. The final approver will probably vary depending on the grade of the Requester: the CEO won't want to bother themselves with approving the vacation arrangements of the janitorial staff.
You will need some rules to enforce who can be an Approver of any given Requester's holidays. Unless you have an exceedingly flat organisation you will find you have a hierarchy of workers and managers. For instance, a Team Leader or a foreman - individuals who are in other respects "workers" rather than "managers" - may be in the chain. Also you may need to consider other aspects of the organisation. Fr instance, if the employee wishes to carry leave over to the next year that may require approval from the HR dept, somebody who normally has no managerial responsibility for the employee whatsoever.
Edit 2
Okay, so we are modelling an arbitrary set of rules rather than a realistic scenario.
Let's see. Each User fits into a single category, defined by these tasks:
Managers and Top Managers have no behaviours in common. Consequently, the first model is the correct one.
我会把这些塑造成演员。他们不是系统的域，而是系统的用户。您会用“想要糖果的学童”、“想要烟草的学童家长”、“店员”等来模拟商店的库存系统吗？虽然只有商店经理（参与者）可以在没有收据的情况下退款，但在系统级别重要的是系统识别商店经理的密钥，并且是软件中的权限令牌而不是参与者所扮演的角色。
您描述的系统域是休假请求和用户帐户，某些用例意味着某些帐户有权对休假请求执行某些状态转换。
将用户/经理/员工建模为参与者和角色的区别在于，您可以专注于对需要放入系统中的内容进行建模，因为不必具有参与者的层次结构 - 您开始在用例和系统中使用抽象实体层面，而不是参与者层面。思考“这在代码中如何工作”并不总是一个坏主意，至少就问“为什么要费心编写这种区别”而言。
I would model these as actors. They are not the domain of the system, but the users of the system. Would you model a shop's inventory system with 'school-kid who wants sweets', 'school-kid's parent who wants tobacco', 'clerk' etc? Although only a store manager (actor) can give refunds without a receipt, what matters at the system level is that system recognises the store manager's key, and it's that permission token which is in the software rather than role the actor takes.
The domain of the system you describe is vacation requests and the user account, and some of the use cases mean that some of the accounts have permission to perform certain state transformations to a vacation request.
The difference in modelling User/Manager/Employee as actors and roles is that you can focus on modelling what you need to put into the system, as don't have to have hierarchies of actors - you start using abstraction at the use case and system entity levels, rather than in the actors. It's not always a bad idea to think 'how would this work in code', at least as far as asking 'why bother coding this distinction'.