域名服务的最佳设计

Question

我对我的域名服务的最佳设计有疑问。用例是根据用户选择的条件创建一些实体。

将使用此服务的应用的工作流程：

1. 用户选择一些条件（如日期和其他数据）
2. 他得到了一份＆＃34;命题列表＆＃34;实体他可以选择所有这些，或只选择一些。
3. 创建实体

域名服务的最佳设计是什么？我有两个想法：

解决方案1 ​​

interface IMyDomainService
{
    IEnumerable<EntityProposition> GetEntitiesPropositions(Conditions conditions);
    void CreateEntities(Conditions conditions);
}

在这种情况下，我可能会在服务上使用一些私有方法，这两种方法都将使用。 EntityProposition 类基本上是视图中显示内容的1：1。该类中有一些数据不属于实体本身。

解决方案2

interface IMyDomainService
{
    IEnumerable<EntitiyData> GetDataForEntities(Conditions conditions);
    void CreateEntities(IEnumerable<EntityData> entities);
}

解决方案1中的私有方法现在在接口中公开了。 EnityData 类包含与创建实体本身相关的实体的所有数据，并显示所有数据以供查看。

添加一些上下文： 此服务现在由ASP.NET MVC控制器直接使用。在我看来，如果我使用解决方案＃2，我将不得不创建一些额外的应用程序服务，因此它将包含创建数据和创建实体的逻辑。

编辑1

我会从不同的角度提问：我的控制器应该是这样的：

public ActionResult GetPropositions(Condtidions condtitions)
{
    var entitiyData= service.GetEntityData(conditions);
    return Json(entitiyData.ToViewModel());
}

public void CreateEntities(Conditions conditions)
{
    var entitiyData= service.GetEntityData(conditions);
    service.CreateEntities(entitiyData);
}

或：

public ActionResult GetPropositions(Condtidions condtitions)
{
    var propositions = service.GetPropositons(conditions);
    return Json(propositions.ToViewModel());
}

public void CreateEntities(Conditions conditions)
{
    service.CreateEntities(conditions);
}

当然这是一个简化的例子，只是为了说明我的观点。

编辑2

正如后续行动：首先我选择了解决方案＃2，但后来我的要求发生了变化，我不得不回到解决方案＃1。背后的原因是，在生成命题之后，用户可以选择其中几个，但具有相同的范围（条件）。

Answer 1

最常见的情况是什么？创建多个实体或创建一个实体？

此外，我不会在方法名称中使用Entites，很明显服务与实体一起使用。

对我来说，这个名字听起来就像是用服务包装存储库。这是一个很大的禁忌。 DDD中的服务是域实体的扩展，用于强制逻辑，您必须在同一业务案例中使用两个或更多实体。

如果您只需要获取实体，修改它并保存它，您应该直接使用存储库（无需抽象抽象）。

interface IMyDomainRepository
{
    IEnumerable<EntitiyData> GetData(Conditions conditions);
    void Create(IEnumerable<EntityData> entities);
}