java - Best practice to inform client about the itemId newly created -



java - Best practice to inform client about the itemId newly created -

i own ddd/cqrs application.

my question concerns handling of item creation through post (rest).

cqrs (based on cqs principle) promotes commands should never homecoming value. queries there that.

so wonder how handle utilize case of item creation.

here's current command handler pattern (light sample (no interfaces etc.)):

@service @transactional public createitem { public void handle(createitemcommand command) { client customer = customerrepository.findbyid(command.customerid); itemid generateditemid = itemrepository.nextidentity(); //generating guid customer.createitem(generateditemid, .....); } }

by reading this article, easy method declare output property in command, populated @ end of handle method this:

public void handle(createitemcommand command) { client customer = customerrepository.findbyid(command.customerid); itemid generateditemid = itemrepository.nextidentity(); //generating guid customer.createitem(generateditemid, .....); command.itemid = generateditemid; //populating output property }

however, see 1 drawback approach: - command, in theory, meant immutable.

this itemid sent calling controller (webapp) through location header status 201 or 202 (depending if expect async or not).

an other solution allow controller initialize guid accessing repository itself, letting command immutable:

//in controller: itemid generateditemid = itemrepository.nextidentity(); //controller generating guid createitem.handle(command); // setting here location header (201-202) containing url newly created item using previous itemid.

drawback: controller (adapter layer) accessing straight repository ..., low-level imo.

my extreme client beingness javascript application, might have solution allow javascript generate guid, , feed createitemcommand before sending whole command server.

advantage: no more issues potential violation of cq(r)s guidelines. drawback: should check validity of passed id @ server side. although there have index unique on preventing unexpected insertion in database.

what best (or good) strategy handle this?

i developer of crm application based on cqrs pattern. tend see commands immutable. team decided on, ids generated on client have immutable commands. ok, using uuids. quite confident, ids valid , there no id collisions. went approach point - can recommend this. in scenario client knows ids.

sometimes happens though - in manual testing - create command dispatched twice same id. in case add-on of events in event store fails (we utilize event sourcing) duplicate key exception. exception passed controller. in fact homecoming results command executions phone call back, though it's "everything ok" of time - no exception thrown. command validation done way. using command bus concept.

i recommend taking @ axon framework. utilize it, provides mutual building blocks, , works. maybe can inspirations that!

java architecture domain-driven-design cqrs

Comments