CQRS Event Sourcing handling update of entity using requests-CodePudding

I'm developing this JavaEE REST microservice oriented CQRS EventSourcing app, i have this entity (Artwork) with many fields and i have to record each update to this entity according to EventSourcing pattern (basically each update creates a new event, the artwork is then rebuild using these events).

My approach basically works, but i'm stuck with a "compliance" towards HTTP standards, basically i want to avoid a "generic" update in which you update the whole entity because it will be a mess to handle each single field update (and consequent event generation).

So this is what I did.

Let's say that i have this entity:

public entity{
       int id;
       String field1;
       String field2;
       ...

Then i created as many requests as many fields i have to update (not all fields can be updated, such as the ID)

public field1UpdateRequest{
      field1 newvalue;
}

and the same for field 2.

These updated are handled using a PUT request, when such a request arrives, it is handled by something like this:

HTTP → Controller→ Service → (DAOS etc.)

So in the controller class i have a PUT http://...//updatefield1 method that accepts field1UpdateRequest objects.

My question is:

Is this right to do? How can i explain that this is right (if it is)? should these requests be PATCH more than PUT? Should a generic PUT request also be included? (Even if I'm scared that this will make the event sourcing part more difficult)?

Thanks, and i hope you will have a merry Christmas.

CodePudding user response：

In a CQRS spproach, it's important to remember that the C stands for Command. Every request to your "write-side" is thus a command. A generic "here is the new value for this resource" request (which is what REST tends to lead to) can be interpreted as a "use this value henceforth" command, but it is a bit of an impedance mismatch with CQRS, because it's a fairly anemic command. There are definitely cases where having that in an API can be called for (and if it's an exceptionally rare request, you may even be able to get away with modeling it as a single "new beginning" event rather than teasing out finer-grained events; this has the cost of shifting some complexity out to consumers of the events).

With that in mind, an alternative approach that updates parts of an object is a little more of a fit with CQRS (though in this case, you are shifting some complexity to requestor, at least if that requestor wants to do wholesale updates). HTTP PUTsounds proper to me: the command is "use this value for this field/component of the entity".

That said, an even more CQRSy API would instead focus on the higher-level activities which motivate a change to the entity. For instance if you're tracking the current owner of the artwork as of when it was sold, you might have a currentOwner and a currentOwnerAcquired field in your artwork entity. When recording a sale, you would want to update both, so a POST /artworks/{artworkId}/transferOwnership endpoint taking something like

{
  "transferor": "Joe Bloggs",
  "transferee": "Jack Schmoe",
  "date": "2021-12-24T00:00:01Z"
}

would allow the update to be a single transaction and allow you to encode the "why" as well as the "what" in your events (which is an advantage of event sourcing).

CodePudding user response：

So in the controller class i have a PUT http://...//updatefield1 method that accepts field1UpdateRequest objects. Is this right to do?

It might be, but it probably isn't.

Here's the key idea: your REST API is a facade; it supports the illusion that your server is stores and produces documents. In other words, your providing an interface to your data that makes it look like every other site on the web.

The good news: when you do that, you get (for free!) the benefits of a bunch of general purpose work that has already been done for you.

But the cost (of these things that you get for free) is that - for everything to "just work", you need to handle the impedance mismatch between HTTP (which is based on an idiom of documents) and your domain model.

So I send to you messages to "edit your documents", and you in turn figure out how to translate those messages into commands for your domain model.

In HTTP, both PUT and PATCH have remote authoring semantics. Both of those messages mean "make your copy of the document look like my copy". They are the flavor of HTTP messages you would use to (for example) edit the title of an HTML document on your web server.

The semantics are fundamentally anemic. My message tells you how I want your copy of the document to look, your server is responsible for figuring out how to achieve that.

And that's fine when you are working with documents, or using documents as a facade in front of a data model. But matching remote authoring requests with a domain model are a lot harder.

(Recommended reading: Greg Young 2010 on task based user interfaces).

In the case of a domain model, you normally want to send to the server a representation of a command message. HTTP really wants you to deal with command messages in one of two ways:

treat the command message as a document/resource of its own, to be stored on the server (the changes to the domain model are a side effect of storing a new command message)
POST the command message to the resource most directly impacted by the change.

(See Fielding, 2009; it is okay to use POST).

In both cases, the HTTP application itself knows nothing about what's going on at the domain level, it is only concerned with the transfer of documents over the network.

HTTP doesn't really place any constraints on your resource model - if you want to publish all of your information in one document, that's fine. If you want to distribute your information across many documents, that's also fine.

So taking a single entity in your domain, and distributing its information across many resources is fine.

BUT: remember caching. HTTP has simple rules for automatically invalidating previously cached responses; separating the resource you use for reading information from the resource that you use for editing information makes caching harder (caution: caching is already one of the two hard problems).

In other words: trade offs.