如何在 rest api 中使用域聚合根？

Question

我是领域驱动设计的新手，对领域服务的分离有疑问。

我有一个 Bucket 和 Item 个实体。所以桶是聚合根。项目在 Bucket 下。简单点赞关注

public class Item: Entity{
    public Guid BucketId {get;set}
    public string Name {get;set}
    
    public Item(string name){
        Name = name;
    }
}

public class Bucket: Entity{
    public string Name {get;set}
    public IEnumerable<Item> Items {get;set}

    public void AddBucket(string name){
        Items.add(new Item(name));
    }
    
    public void RemoveBucket(string name){
        Items.Remove(Items.First(x=>x.name == name));
    }
}

那么我应该创建两个单独的应用程序服务类（BucketsService、ItemsService）和 api 控制器（BucketsController、ItemsController）吗？
或者我应该只创建一个名为 BucketsService 的服务服务并在该服务中添加所有添加、删除项目操作吗？

Answer 1

考虑到所有操作都应该从根开始执行，只有 BucketService 似乎是一个合乎逻辑的起点，但没有任意规则，例如“您应该只拥有以 AR 命名的服务”。我通常尝试根据服务提供的行为集而不是 AR 名称来命名服务 class。

例如，我设计了一个提供税务提醒的应用程序。提醒的信息是从另一个系统导入的，数据有时必须在发送前由代理更正。

对于那个系统，我有一个 ImportService、一个 DeliveryService 和一个 CorrectionService，尽管它们都以某种方式处理 Reminder AR。上下文也很重要。在那种情况下，我只有一个 BC 和一个 Reminder AR，但即便如此，考虑“上下文”有助于专注于分组行为。

请注意，“服务”后缀仍然是技术产物。如果找不到更好的名称，有时根据它们所代表的战术 DDD 模式来命名概念是合适的，但尽可能避免使用它

例如

BasketAggregateRoot ⟶ Basket：是的，我见过“AggregateRoot”后缀

CustomerDeactivatedDomainEvent⟶CustomerDeactivated

ReminderExpirationEventHandler⟶ReminderExpirationPolicy

PS：请注意 public IEnumerable<Item> 目前破坏了 AR 的封装，因为它允许修改 Item 实例而无需 Bucket 意识到。

如何在 rest api 中使用域聚合根？

How to use domain aggregate root in rest api?

domain-driven-design