Personally, I like to use this command side projections to solve similar problems. This can be valuable in situations when you can not make a decision in the command handler based on the state of the event-sourced aggregate only, for example, uniques (we have to guarantee that all User aggregates have unique Name/Email). As Allard stressed already, you should keep this small projection within the command component/module. This projection should not expose any Query API outside of this component, it should be used only inside the command component/module to make the right decision in your aggregate(s). Additionally, you can choose to use Subscribing Event Processors to materialize this small projection. Subscribing Event Processors are invoked by the thread managed by the publishing mechanism (in the same transaction) and they will keep your projection immediately consistent with the state of your aggregate(s).
This way your command side (your business logic) owns this projection data.
Please do not misuse this :), you should try to make decisions in your command handlers based on the aggregate state only, and use this command side projections as a last resort.
Best,
Ivan