DDD中的领域对象建模哪个更好？

Question

请考虑到我们正在为 HR 相关的应用程序构建工作，这里我们需要对有关部门的域对象进行建模，employee.I想知道是否应该使用嵌套聚合对域对象进行建模，尤其是嵌套在本身。

我正在尝试考虑以下两种不同的样式：

解决方案 #01，具有嵌套聚合的模型员工。

public class Employee : BusinessObject, IEmployee
{
     IList<IEmployee> ManagedStaffs { get; set;}
     IEmployee Supervisor { get; set;}
}

因此我们可以将其用作：

var emp = empRepository.Get(1);
// dot accessors
var numberOfPeople = emp.Supervisor.ManagedStaffs[0].ManagedStaffs.Count;

解决方案 #2，没有嵌套聚合的模型员工。

public class Employee : BusinessObject, IEmployee
{
    //without nested aggregate
}

public class Supervisor : Employee, ISupervisor
{
    IList<IEmployee> ManagedStaffs { get; set; }
}

因此我们可以将其用作：

var emp1 = empRepository.Get(1);
// GetManagedStaffs needs a parameter which is a ISupervisor
var empList1 = empRepository.GetManagedStaffs(emp1.Supervisor);
var empList2 = empRepository.GetManagedStaffs(empList[0]);
var numberOfPeople = empList2.Count;

如果我们想在没有 ORM 的情况下持久化域对象，只需 ADO.NET，解决方案 #2 看起来好多了。

如果我们想在解决方案#1 中使用点访问器，需要引入一个透明的 ORM 框架，并且由于递归嵌套聚合而欢迎延迟加载。

我认为这里确定哪个是更好的解决方案的关键点是基于如何处理嵌套聚合。

请问您有什么建议吗？或者我有什么需要更正的？

谢谢。

Answer 1

第二种解决方案要好得多。

起初聚合应该很小。通常并非所有操作都需要所有聚合组件。如果聚合很大——它的所有部分都将加载到内存中，那么为此类聚合实现持久化逻辑将更加困难，对数据库的查询将更加复杂（显然，持久化操作会对大型聚合产生巨大的性能影响）。您希望通过 ORM 的延迟加载功能来减轻这些影响，但是延迟加载需要更多的关注和控制——您应该确切地知道加载了什么以及何时加载。同样从性能的角度来看，通过单个查询加载所有聚合比在延迟加载中通过多个查询加载更好。

其次，第一个场景的使用违反了 Demeter 法则 (https://en.wikipedia.org/wiki/Law_of_Demeter)。从这一点来看，#2 场景使用更干净。

Answer 2

#方案二很好。主管和员工之间有很好的 "is-a" 关系。但是这种关系将来会引入耦合问题。您更改员工我担心主管也会受到影响。另一个解决方案可能是支持 "Composition over inheritance" 以及#solution 1。决定权在你

DDD中的领域对象建模哪个更好？

Which one is better of domain object modeling in DDD?

orm

ado.net

domain-driven-design

aggregateroot