Is CQRS correct for my domain?

Question

I am modelling an archive which is part of an video demand system. Think of the archive like windows explorer where multiple users can create folders, upload videos, restructure folders etc. There are business rules (permissions) which determine if the user is allowed to do the task (i.e. rename folder, move folders, view folders etc).

I have modeled each folder as an aggregate root and moving one folder to another folder appears to affect two aggregate roots.

From what I understand is I should send an event to modify the other aggregate. However what concerns me is if the second folder has also been modified (say deleted or removed from the system) then I need to send a compensating command to undo the first aggregate change.

I would prefer some sort of transaction that deals with the move (change on both aggregates) together and if it fails then at least I do not need to undo the first part of the move or raise the first part of the event.

This leads me to, is CQRS right for the problem I am trying to solve? And if so could it be that my aggregates are wrong?

Fisticuffs

Answer 1

In DDD the Aggregate should represent the transactional boundary. A transaction that requires the involvement of more than one aggregate is often a sign that either the model should be refined, or the transactional requirements should be reviewed, or both.

This a pure DDD issue and is independent of CQRS or any other architectural pattern.

On the other hand, do you really need to reinvent hierarchical structures like folders containing files? As far as I can tell this has been a solved problem for quite some time. Maybe there's no inherent advantage in formalizing that specific domain once again.

Domain modeling using the patterns of DDD makes most sense in bounded contexts where (1) the domain is very complex and (2) modeling the domain will give your software a real (e.g. competitive) advantage over similar applications. If that specific bounded context is rather simple and/or remodeling it doesn't bring a really great advantage, you are better off using the simplest possible solution.

This represents the IMHO most important concept in Domain-Driven Design, which is Focus on the Core Domain

Sparkle

Thank you for your reply. When you said "do you really need to reinvent hierarchical structures...", can you elaborate a bit more? I have concepts of permissions and some other rules such as files and folders cannot be mixed (i.e. folders must contain other folders or just files). In the future we have the concept of shortcut to files (reference counting). All this to me seems like the domain or as I thought of as the business layer. I am pretty new to DDD and at this stage I have no persistence or events being raised in my domain. When the reads increase, I thought that is where CSQR helps. – Fisticuffs

Sounds like a file system to me. What I'm asking is, do you really need to re-invent a concept, that has been around for many years. Will your model introduce anything new so that your newly modeled application will have a significant advantage over any existing file system. Basically DDD is less software analysis, and more business analysis. DDD is about formalizing the domain and usually isn't required, when the domain has already been extensively formalized. Long story short: Don't reinvent the wheel. – Sparkle

Sorry, I downvoted your answer. 1) It does not provide any value -- I believe, OP is asking whether it's technically possible/reasonable to model their software DDD way given the use-case they are struggling with. So, do you know how to model it DDD-way or not? 2) "Focus on the Core Domain" is about prioritizing what you spend your time and effort on -- not about whether software should exist or not. 3) "Basically DDD is less software analysis, and more business analysis." -- I belive, this contradicts what Evans wrote in first chapters of his book. 4) Patronizing tone of your comment. – Gloria