asp.net mvc - Guid of created aggregate root in CQRS -
looking @ code here:
[serializable] public class createclientcommand : command { public string clientname { get; private set; } public string street { get; private set; } public string streetnumber { get; private set; } public string postalcode { get; private set; } public string city { get; private set; } public string phonenumber { get; private set; } public createclientcommand(guid id, string clientname, string street, string streetnumber, string postalcode, string city, string phonenumber) : base(id) { clientname = clientname; street = street; streetnumber = streetnumber; postalcode = postalcode; city = city; phonenumber = phonenumber; } } the guid here relevant command. not guid of (potentially) created aggregate root. best practice obtain guid , how potential validation errors communicated the code puts command on bus? illustration this:
_bus.publish(new createclientcommand( guid.newguid(), _clientdetailsreport.clientname, _clientdetailsreport.street, _clientdetailsreport.streetnumber, _clientdetailsreport.postalcode, _clientdetailsreport.city, _clientdetailsview.phonenumber)); _bus.commit(); i understand cqrs implements eventual consistency. means might take while before client created. mvc/cqrs code uses approach:
[httppost] public actionresult add(diaryitemdto item) { servicelocator.commandbus.send(new createitemcommand(guid.newguid(),item.title,item.description,-1,item.from,item.to)); homecoming redirecttoaction("index"); } obviously, index page might show grid containing diaryitems , user might able see latest created diaryitem (potentiality after while). feedback much appreciated. thanks.
are asking distinction between id command itself, versus id of entity might create? former typically infrastructure concern, found on message envelope, buried in rpc protocol, or like. latter part of domain. (though in many cases, it's nice treat id of entity infrastructure concern well, since might take convenience in persistence model.)
asp.net-mvc domain-driven-design cqrs ncqrs
No comments:
Post a Comment