DDD update via REST

Question

I am new to DDD, and I am trying to figure out a way to update aggregate by using a PUT verb.

If all properties in the aggregate have private setters, then it's obvious I need to have set of functionality for every business requirement. For an example

supportTicket.Resolve(); 

It's clear for me that I can achieve this with an endpoint such as /api/tickets/5/resolve, but what if i want to provide a way to update whole ticket atomically?

As an example, user can make a PUT request to /api/tickets/5 with a following body

{"status" : "RESOLVED", "Title":"Some crazy title"}

Do I need to do something like this in the ApplicationSercvice

if(DTO.Status != null && dto.Status == "RESOLVED")
  supportTicket.Resolve();
if(DTO.Title != null)
  supportTicket.setNewTitle(DTO.title);

If that's the case and changing ticket title has some business logic to prevent changing it if the ticket is resolved, should I consider some kind of prioritizing when updating aggregate, or I am looking at this entirely wrong?

Answer 1

Domain Driven Design for RESTful Systems -- Jim Webber

what if i want to provide a way to update whole ticket atomically?

If you want to update the whole ticket atomically, ditch aggregates; aggregates are the wrong tool in your box if what you really want is a key value store with CRUD semantics.

Aggregates only make sense when their are business rules for the domain to enforce. Don't build a tractor when all you need is a shovel.

As an example, user can make a PUT request to /api/tickets/5

That's going to make a mess. In a CRUD implementation, replacing the current state of a resource by sending it a representation of a new state is appropriate. But that doesn't really fit for aggregates at all, because the state of the aggregate is not under the control of you, the client/publisher.

The more appropriate idiom is to publish a message onto a bus, which when handled by the domain will have the side effect of achieving the changes you want.

PUT /api/tickets/5/messages/{messageId}

NOW your application service looks at the message, and sends commands to the aggregate

if(DTO.Status != null && dto.Status == "RESOLVED")
  supportTicket.Resolve();
if(DTO.Title != null)
  supportTicket.setNewTitle(DTO.title);

This is OK, but in practice its much more common to make the message explicit about what is to be done.

{ "messageType" : "ResolveWithNewTitle"
, "status" : "RESOLVED"
, "Title":"Some crazy title"
}

or even...

[
  { "messageType" : "ChangeTitle"
  , "Title" : "Some crazy title"
  } 
, { "messageType" : "ResolveTicket"
  }
]

Basically, you want to give the app enough context that it can do real message validation.

let's say I had aggregates which encapsulated needed business logic, but besides that there is a new demand for atomic update functionality and I am trying to understand a best way to deal with this.

So the right way to deal with this is first to deal with it on the domain level -- sit down with your domain experts, make sure that everybody understands the requirement and how to express it in the ubiquitous language, etc.

Implement any new methods that you need in the aggregate root.

Once you have the use case correctly supported in the domain, then you can start worrying about your resources following the previous pattern - the resource just takes the incoming request, and invokes the appropriate commands.

Answer 2

Is changing the Title a requirement of Resolving a ticket? If not, they should not be the same action in DDD. You wouldn't want to not resolve the ticket if the new name was invalid, and you wouldn't want to not change the name if the ticket was not resolvable.

Make 2 calls to perform the 2 separate actions. This also allows for flexibility such as, the Title can be changed immediately, but perhaps "resolving" the ticket will kick off some complex and time consuming (asyncronous) work flow before the ticket is actually resolved. Perhaps it needs to have a manager sign off? You don't want the call to change "title" tied up in that mix.

If needs be, create something to orchestrate multiple commands as per @VoiceOfUnreason's comment.

Wherever possible, keep things separate, and code to use cases as opposed to minimizing interacitons with entities.