把复杂的，多领域相关的逻辑：在服务层或模型本身？
问题描述：
我想在我的项目中应用领域驱动设计原则，但无法确定我应该如何处理依赖模型的业务逻辑。把复杂的，多领域相关的逻辑：在服务层或模型本身？
例如，假设此场景：
我有Person和Car域模型。每个人都适合从基于年龄/预算/偏好等的数据库购买某些汽车。在我的模型中，我希望有一个适合此人使用的汽车列表（SuitableCars）。
public class Person
{
public List<Car> SuitableCars {get; set;}
}
但为了做到这一点，现在，我已经调用一个服务方法（GetSuitableCarsForPerson）从资料库（含仓库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);
}
}
据我所知，服务应保持薄（ref），并用来让你把不收的DomainModel相关业务在其中。但我相信我所描述的逻辑属于模型本身。
那么，如何处理这些类型的逻辑，我应该访问相关模型并执行各种自定义验证/过滤器以获取适当的数据？
谢谢。
答
看起来好像一套人适用的汽车的定义取决于人的模型以外的因素，并且可以独立于人而变化。这套适合的汽车不仅取决于人的喜好，还取决于所有汽车的组合。该组汽车独立于人而变化，因此针对给定人的适合的汽车组是确定适合的汽车组的操作的缓存。这些观察结果表明，存储库或域服务应该为一个人返回一组合适的汽车，并且人与该组合适的汽车之间的关联不应该直接在人员模型上表达。什么可能是一个适当的关联，直接表达人的模型是一组车被人指定为优先模型，因为在这种情况下，人是这个数据的“所有者”。在DDD中，直接在模型中或通过使用存储库来表达关联是可以接受的，并且选择具体的方法取决于几个因素，其中一些因素如上所述。请看this series of articles深入了解如何设计模型。