Question

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

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

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

但是为了现在这样做，我必须调用服务方法（GetSuitableCarsForPerson）从db（DI with repository）获取数据，运行我的（有时相当复杂的多模型依赖）自定义逻辑并得到汽车。

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），并用于让您将Not-DomainModel相关业务放入其中。但我相信我所描述的逻辑属于模型本身。

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

Answer 1

希望这个答案https://stackoverflow.com/a/1209765/145595能提供一些指导。

Answer 2

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

放置复杂的，多域相关的逻辑：在服务层或模型本身？

2 个答案: