CODEWITHSUNDEEP
domain-driven-design
barteloma
barteloma

Reputation: 6875

How to use domain aggregate root in rest api?

I am new at domain driven design and have a question about separation of domain services.

I have a Bucket and Item entities. SO the Bucket is aggregate root. Item is under the Bucket. Simply like following.

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));
    }
}

Upvotes: 0

Views: 400

Answers (1)

plalx
plalx

Reputation: 43718

Given all operations should be performed from the root, only having BucketService seems like a logical start point, but there's no arbitrary rule such as "you should only have services named after ARs". I usually attempt to name the service class according to the set of behaviors it provides rather than the AR names.

For instance, I designed an application that delivered tax reminders. The reminder's info was imported from another system and data sometimes had to be corrected by agents prior to being sent.

For that system I had an ImportService, a DeliveryService and a CorrectionService although all of them dealt with Reminder ARs one way or another. Context is also very important. In that case I had a single BC and a single Reminder AR, but even so thinking about the "context" helped to focus on grouping behaviors.

Note that the "Service" suffix remains a technical artefact. Sometimes it's appropriate to name concepts against the tactical DDD pattern they represent if you can't find a better name, but try to avoid it when possible

e.g.

BasketAggregateRoot ⟶ Basket: yes, I've seen "AggregateRoot" suffixes

CustomerDeactivatedDomainEvent ⟶ CustomerDeactivated

ReminderExpirationEventHandler ⟶ ReminderExpirationPolicy

PS: Note that the public IEnumerable<Item> currently breaks the AR's encapsulation, because it allows to modify an Item instance without the Bucket being aware.

Upvotes: 1

Related Questions