CQRS/DDD response

gistfile1.txt

original post @ https://www.linkedin.com/feed/update/urn:li:activity:6881954451964461056?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6881954451964461056%2C6882013851898933249%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A6881954451964461056%2C6882320295986917376%29

I think there is a lot to unpack here, and it is probably a very long blog post with very descriptive meaning to terms
around system/software design. For more in-depth information, see CQRS Documents by Gregg Young. Also, look 
at Event Modeling from Adam Dymitruk. Both are exceptional.

However, I will try to be concise. CQRS means separating your writes from your reads. In other words, when some 
actor (user, external system, what have you) issues a command (write side) to the system, it is only changing its state. 
The system's internal state is critical here, and the system shouldn't leak the internal structure out (encapsulation and 
information hiding). The Command side does not mean the system doesn't return a typical representation of the system or 
entities after the command. It could, and I think in some cases is worth it. The Query(s) side of CQRS is precisely what 
it says. Notice I stuck an (s) at the end of Query because I could have multiple system representations depending on what 
I want to know.

Now onto DDD. For me, DDD is all about how systems communicate and are organized. Both Red (Vernon) and Blue (Evans) books 
talk about strategic patterns and context communication mechanisms (Context Maps). One of them being Subdomains and the 
other Bounded Contexts. Those patterns (to me) seem to be about organizing your use cases, where a use case is the intent 
of the actor trying to change your system. In my head, use cases map nicely to the Command side of CQRS, and those Commands 
tend to have a symbiotic relationship with other use cases. Those symbiotic use cases tend to have similar representations 
of state but aggregated differently (query side). In the book, Righting Software (Lowy), he states similar ideas around 
Services, Managers, and Engines with decomposition around volatility and how they communicate. I highly recommend his book 
and leave the audience to compare and contrast the approaches.

So to your original question. Is it more complex to implement CQRS with DDD? If you implement DDD, you hopefully are 
already breaking things down in a CQRS manner because you are trying to understand the domain and the intent of its actors. 
Notice I have not talked about implementation details at all, and I did not speak about Active Record, classes, modules, 
Repository, Datamapper, Value objects, etc. I think those confuse the actual reason why the ideas are essential.

I think complexity lies in not understanding the domain and in how most software is currently developed, which is not bad 
in a lot of cases. I believe we have lovely tooling around building web applications, but it is designed in a certain way 
to solve a specific problem. It is effortless to generate a relational relationship using Rails, use active record finders 
to query that data directly, and spit it directly out to the requestor, exposing your whole internal data structure, Parnes 
would cry. That by its very nature is so much easier than going, "ok, thats great, but how does that fit into the total 
organization of the system or set of systems? What are the actors trying to do?" Other questions then become, do we want 
other systems accessing this data directly by queries? Who has ownership over the data, and who checks the business 
invariants? What uses cases belong where? What should the systems expose? DDD, CQRS, Services, Managers, Engines, pick your 
poison, are all simply trying to wrangle complexity.

In summary, after being in some reasonably large codebases, I think in business information systems, which many of us 
engineers design and build, there should be some architecture pattern at the start to at least organize and name use cases 
in the system. It is exceedingly hard to wrap your mind around large codebases without that small thin layer. The other 
possibility is that I am a simple guy and can not keep all the moving parts around in my noodle for sizeable complex 
business systems. CQRS, DDD, and other higher-level strategic patterns hopefully allow engineers to understand what they 
are working on, how it fits into the whole, and how the messaging between systems operates. There are business advantages 
also, but I am sticking to the technical side.