Now I have a business rule that says all items must be uniquely named
You've entered into a problem space referred to as set validation. Which means you need to read this essay by Greg Young before you do anything.
With eventual consistency it's perfectly possible for this data to be out of date, so how should I handle that?
There are only three answers that I know of
Accept eventual consistency which is to say, change the requirements. Part of the promise of ddd (which is where "aggregate root" comes from) is that not only do you align the model with the business, but you also have a strategy for separating real requirements from imagined ones, and exploring alternative implementations -- not only of the model, but of the business itself.
For uniqueness constraints - if the aggregate makes a good faith effort to check for uniqueness, and you have a process in place that allows you to report duplicated (based on reading the event streams), and a reasonable mitigation strategy when a duplicate does appear, is it really that important that the model rejects all duplicated names?
You also need to be clear that your model is in charge of the property in question. Is your model deciding what the name is, or is it simply being informed that someone else made a decision? In the latter case, you are talking about events, not commands, and you need a different strategy (process managers, aka downstream event processors).
Move the business rule relational databases are really good at set validation. If your event store happens to be a relational database, then you write the username to a username table with a column constraint in the same transaction that persists the events. The domain knowledge has leaked out of your model, which has some negatives -- you lose the ability to federate the event histories into multiple databases.
In theory, the relational database could be separate from the event store, with a two phase commit coordinating the two. I've yet to find any authorities describing a scenario when they were happy to have that alternative.
Change your aggregate boundaries If you need transactional consistency in the set, then the set is part of the domain model, and needs to be represented inside the boundary of some aggregate -- for your example, an "ItemCatalog" perhaps. Probing at the ubiquitous language with domain experts may help discover a new aggregate that is responsible for this constraint.
If Item behavior is tightly coupled to names (there's a business rule that says you can only DoubleThePrice of items when the name current starts with a vowel?), then the Item entity itself is going to have to become part of the same aggregate, and you are going to need to accept the contention in concurrent edits to different contexts.
It's worth keeping in mind too whether you are implementing the business constraint in the correct model -- ie, the correct bounded context. For example, the Marketing department might care a lot about the uniqueness of item name, where the Warehouse doesn't care. Which suggests that you are missing a change in the ubiquitous language. Remember, if the concept means different things to different parts of the business, there are supposed to be different models.
