DDD并在域类中获取其他信息

我想我已经阅读了16,154个关于DDD和最佳实践的问题,博客文章,推文等.对这种类型的另一个问题道歉.假设我的数据库中有三个表,User,Department和UserDepartment.一切都很简单.我需要构建一个层次结构,显示用户可以访问哪些部门.问题是我还需要向他们有权访问的那些部门展示.

是否最好在我的用户类上使用GetDepartments()方法？现在我有一个GetDepartments用户服务(字符串userName),但我觉得这不是最佳解决方案.如果user.GetDepartments()是首选,然后我如何才能访问存储库获取父部门对于那些用户有权访问？

不要认为这很重要,但我正在使用实体框架.

public class User
{
    [Key]
    public int UserId { get; private set; }

    [Display(Name = "User Name")]
    public string UserName { get; private set; }

    [Display(Name = "Email")]
    public string Email { get; private set; }

    [Display(Name = "UserDepartments")]
    public virtual ICollection UserDepartments { get; private set; }

    public List GetDepartments()
    {
        // Should this be here? and if so, what's the preferred method for accessing the repository?
    }
}

Alexey Raga.. 7

DDD更多的是关于行为,这也意味着它是面向TDA(告诉,不要求).

通常,您可以以告诉他们要做什么的方式构建聚合,而不是询问信息.

更重要的是,如果聚合需要一些额外的信息来执行其行为,那么通常不是他们的工作来确定从哪里获取这些信息.

现在,当您说您的用户聚合具有GetDepartments方法时,它会引发响铃.聚合是否需要此信息才能执行任何类型的行为？我不这么认为,只是你想要显示一些数据.

所以我在这里看到的是你试图根据数据表构建聚合,而不是反对行为.这在应用DDD时实际上是#2错误(#1没有考虑有界上下文).

同样,聚合表示系统的业务逻辑和行为.这意味着您不必从聚合中读取.您的阅读方可以更轻松地完成 - 只需向数据库发出一个该死的查询.

但是,一旦你需要问你的系统做的事情-现在你通过聚集做到这一点:AppService服务将加载一个从资源库中,并调用它的行为方式.

这就是为什么通常你的聚合中没有属性,只是表示行为的方法.

此外,您不希望无论如何都要将聚合映射到数据表,这不是他们的工作,而是存储库的工作.实际上,您不希望您的域依赖于任何内容,尤其是基础结构.

因此,如果您想要寻找DDD方向,请考虑以下事项:

构建聚合以封装行为,而不是表示数据表

不要让您的域名依赖于基础设施等.

使存储库负责加载/保存聚合.聚合本身应该对持久性,数据结构等一无所知.

您不必通过聚合读取数据.

想想#4​​,因为你的系统有两个方面:当你刚读取数据并在UI中显示它们时的"读取"方面,以及执行操作时的"命令"方面.

第一个(读取)非常简单:以您想要的方式读取数据的愚蠢查询.它不会影响任何东西,因为它只是阅读,没有副作用.

第二个是当你进行更改,这是怎么回事通过你的域名.

再次,请记住DDD的第一条规则:如果您没有业务逻辑和行为来建模,那么就不要做DDD.