The role of Aggregate roots in a REST API (DDD)

I'm creating a new REST/hypermedia API for an on line auction service.

I'm using this as an exercise to better understand Domain Driven Design approach as for the most part it seems like a good approach.

An example of some of my entities are: Item, Listing, Bid, Purchase, BidHistory etc. I identify the Listing entity as an aggregate root through which I plan to manage Bid, Item etc.

As far as I can tell, the concept of the aggregate root is applicable to my persistence/domain layer and should NOT be a concern of my view layer (in my case JSON or XML resource representations).

Is this the case? And if so, would this mean that it is still okay to expose non aggregate root resources via URI endpoints in my REST API or am I 'constrained' to only exposing aggregate roots through my API's endpoint?

My thought is that aggregate roots are in the realm of the persistence object which is conceptually separate from the domain model and so I should be able to expose both URI such as:

GET /api/v1/listing/465489

and

GET /api/v1/listing/465489/item

regardless of whether or not Listing is the aggregate root of Item or not.

Am I on the right lines here or do I need to adjust my understanding of this before I begin to implement any code?

I'm using this as an exercise to better understand Domain Driven Design approach as for the most part it seems like a good approach.

OK... but they are orthogonal concerns, so be careful.

As far as I can tell, the concept of the aggregate root is applicable to my persistence/domain layer and should NOT be a concern of my view layer (in my case JSON or XML resource representations).

That's right - aggregates are a partitioning of your business domain. Resources are part of your integration domain. See the Jim Webber talk REST - DDD in the Large.

would this mean that it is still okay to expose non aggregate root resources via URI endpoints in my REST API or am I 'constrained' to only exposing aggregate roots through my API's endpoint?

It depends how you mean that. You aren't "exposing" your aggregate roots in any case, you are adapting your domain model for the web. Which means your clients are manipulating resources, and as a side effect of this the resources manipulate the domain model.

So the messages that you send to the domain model from the api are still going to be addressed to the aggregate root, and further traversal will be required to get to the non root entities.

For operations that are safe, you don't really need the aggregate roots at all. The CQRS pattern is built on this idea; that you can read a previously cached representation of the state of the model without risking the business invariant. So creating resources with immutable semantics that provide access to entities in your domain is fine.

Unsafe operations, however, are trickier -- you need to take the semantics of the uniform interface that you expose, and translate that into the appropriate message(s) to send to the aggregate root - because it is behind the root that the authority for validating the changes actually lives.

Recommended topics

Hot tags