So one aggregate is a ChatAggregate which allows people to add comments. However a user can only add one comment per hour or one comment for the entire life time. My domain object cannot keep all comments in memory but I still need my ChatAggregate to apply this business logic. Because of the eventually consistent nature of my view store, I cannot let my aggregates query it for business logic. How does DDD handle when an aggregate needs access to a lot of data?
It re-examines the design to see if the actual requirement is being expressed correctly. A big part of the value prop of DDD is that when the programmers are having trouble fitting the business requirements into the the design, it often
means that the programmers don't understand the real requirements.
To extend your example; you might discover that CommentSubmitted and CommentPublished are actually two different events, and that there is a business process responsible for figuring out if one event necessarily leads to the other.
The write model might look like:
Where submitComment throws an exception if the muted state of the user doesn't support commenting, and the Chat refuses to publish comments where the user has already done so.
The glue that makes this work is a state machine that is listening to the event stream (warning: pseudo-code ahead).
This is a process manager; it's interacting with the domain purely through the api (listening to events, and dispatching commands). It's also scheduling messages to its future self (via the timer).
Note that, as shown here, it doesn't generally get to invoke commands on the domain model directly. The problem is that you are only supposed to update one history per transaction, and the process manager needs to persist its own state transitions.
It's worth noting too the space that has opened up, to push on the requirements: do we mute the user when they submit a comment (and then try to recover if the comment isn't published) or do we only mute the user if a comment is published. Maybe we only mute the user for a few minutes when they submit, but for the full day once we have the acknowledgement that the comment is published, and so on.
The second issue I have is when a domain command is being processed, I want to query other aggregates before processing the command with the target aggregate.
Go right ahead -- that's a perfectly reasonable thing for the application to do. You need to keep in mind that any query you run returns stale results -- you can't ever know what's "now" except within the domain aggregate itself, but "not too long ago" is almost always going to be good enough.
A common pattern for validation is that the human operator (sitting in front of the client), will try to verb, and the app will say "nope - the latest information we have says that we can't do that." But if everything checks out, then the command is dispatched to the server, which can do its own validation prior to sending the command to the aggregate for processing.
But once you are in the aggregate, the only things you should be looking at are the current state of the aggregate, and the state captured in the command.