I am a big user of both CQRS and Event Sourcing, but not in the very narrow sense implied by DDD&#x2F;CQRS&#x2F;ES advocates. In particular, there are two main tenets that I feel are not sufficiently justified.<p>One is the idea that commands are write-only (they are not allowed to return information). The reason for this restriction is fairly unclear, and there are several pieces of information that I believe can be legitimately returned:<p>- Has the command finished executing?<p>- Was it successful? If not, what was the exception thrown?<p>- If the command created something, what is that thing&#x27;s identifier?<p>- For distributed systems, what is a vector clock after the command&#x27;s execution?<p>Another idea is aggregates, especially the fact that each event is bound to a single aggregate and that two aggregates process their associated events independently. I can see how this can be useful, in a NoSQL-ish kind of way: by sacrificing the ability to enforce invariants across multiple aggregates, it becomes trivial to distribute event streams, to quickly compute the state of a single aggregate among millions, and to write to several aggregates in parallel without a global lock.<p>Still, sacrificing those invariants is costly. Many domains will have constraints on uniqueness (e.g. each e-mail address may belong to only one user) or relationship arity (e.g. each student may have at most one internship, each internship may have at most one student), and from my experience, expressing those constraints in an aggregate-based system usually ends up in:<p>- creating a &quot;lock&quot; aggregate with &quot;Locked&quot; and  &quot;Unlocked&quot; events, or<p>- ignoring constraints and providing an user interface to manually resolve violations.<p>I would rather express simple constraints with simple code and have to work hard for optimizations later, than to have to write complex code just to solve an unconfirmed performance issue.