放置复杂的多领域相关逻辑：在服务层还是模型本身？答案

【问题标题】：putting complex, multi-domain related logic: in Service layer or in model itself?放置复杂的多领域相关逻辑：在服务层还是模型本身？
【发布时间】：2012-05-10 08:22:59
【问题描述】：

我想在我的项目中应用领域驱动设计原则，但无法确定我应该如何处理依赖模型的业务逻辑。

例如，假设这种情况：
我有Person 和Car 域模型。每个人都适合根据年龄/预算/偏好/等从 db 购买某些汽车。在我的模型中，我想要一个适合此人的汽车列表 (SuitableCars)。

public class Person
{
    public List<Car> SuitableCars {get; set;}
}

但现在为了做到这一点，我必须调用一个服务方法 (GetSuitableCarsForPerson) 从 db（带有存储库的 DI）中获取数据，运行我的（有时相当复杂的多模型相关）自定义逻辑并获取汽车。

public class PersonService : IPersonService
{
    private IRepository _repo;

    public PersonService(IPRepository repository)
    {
        _repo = repository;
    }

    public List<Car> GetSuitableCarsForPerson(Person person)
    {
        // business goes here right now.
    }

}

所以SuitableCars属性的声明会变成：

private IPersonService _personService;
public List<Car> SuitableCars 
{
    get
    {
        // I have to inject a PersonService in my model. Bad practice?
        return _personService.GetSuitableCarsForPerson(this);
    }
}

AFAIK，服务应该保持精简（ref）并用于让您将与非域模型相关的业务放入其中。但我相信我所描述的逻辑属于模型本身。

那么，如何处理这些我应该访问相关模型并执行各种自定义验证/过滤器以获取适当数据的逻辑？
谢谢。

【问题讨论】：

标签： domain-driven-design business-logic service-layer domain-model

【解决方案1】：

希望这个答案https://stackoverflow.com/a/1209765/145595 将提供一些指导如何继续。

【讨论】：

【解决方案2】：

似乎适合人的汽车集的定义取决于人模型之外的因素，并且可能因人而异。合适的汽车集合不仅取决于人的喜好，还取决于所有汽车的集合。汽车集独立于人而变化，因此给定人的合适汽车集是确定合适汽车集的操作的缓存。这些观察表明，存储库或域服务应该为一个人返回一组合适的汽车，并且一个人和一组合适的汽车之间的关联不应该直接在人模型上表达。直接在人员模型上表达的适当关联可能是该人员指定为首选模型的汽车集，因为在这种情况下，该人员是该数据的“所有者”。在 DDD 中，直接在模型中或通过使用存储库来表达关联是可以接受的，并且选择特定方法取决于几个因素，其中一些已在上文中概述。查看this series of articles，深入了解如何设计模型。

【讨论】：