领域驱动设计问题

Question

我有一个方案需要我的建议。我有一个应用程序，其中有学生和教师两种用户。学生和教师共享一些常见的属性，如FirstName、LastName、电子邮件、UserName、密码等。因此，我从用户那里派生出学生和教师的课程。

现在的问题是，有时候我不知道用户是学生还是老师。类似于在实现自定义成员资格提供程序和GetUser函数时。GetUser带走了userName，但现在我失去了我应该返回的东西。

对于学生函数，我为教师创建了IStudent和ITeacher。但有时我只是想返回一个用户，而不关心他是学生还是老师。但是返回基类似乎也不是一个好主意。

更新：

我认为这是一个好主意，返回用户，甚至没有学生和老师的课。学生和教师只是角色，可以由StudentServices和TeacherServices来管理。

Answer 1

一个经典的场景和一个典型的逃离问题。是的，继承工作总是有痛苦的，因为他们受到了限制。但是，当您将行为注入到类(Es)中时，就会产生好处。现在看来，您似乎已经决定使用User类，而不是将用户作为基类和子类--教师和学生。如果你让老师和学生扮演角色，但在不同的服务中处理他们，这可能是个好主意.嗯，闻起来像我的意见。您可能会在这些服务中出现重复的代码，因为它们都需要处理用户逻辑。

事实是，如果您开始通过在服务层中进行补偿来抵御这样的困难，那么这就是通向一个贫血域模型的道路，在这个模型中，逻辑从域层泄漏到gui或服务层。什么是教师和学生的独特之处，哪些逻辑/行为不同，应该用域层表示。

您可以使用继承(也许是最好的解决方案)，或者将它们作为一个角色来使用--看看Jimmy如何用行为扩展自定义Enum。