Normalmente, você lidaria com esse tipo de coisa no aplicativo, e não no domínio. Por exemplo, um limitador de taxa para restringir o número de edições por BlogPost, talvez outro no próprio comando de edição. Esse tipo de coisa surge na segurança de autenticação, então você pode procurar lá.
Uma segunda abordagem seria tratar os votos para cima ou para baixo como eventos, ao invés de comandos. Esses são eventos externos que seu aplicativo assina, como se estivessem ouvindo eventos emitidos por um modelo de domínio diferente. Um gerenciador de processos de recebimento de dados se inscreve nos eventos e envia comandos para seu modelo em resposta.
A vantagem aqui é que faz sentido tratar os eventos como um lote; Em vez de passar por todos os eventos que você vê, é possível filtrar todos os eventos que são cancelados antes de passá-los para processamento. Você pode usar a aceleração aqui também (novamente, esses não são os eventos do seu modelo, portanto, você não precisa se preocupar em re-hidratar o estado deles; você só usa seus próprios eventos para reconstruir o estado).
Se isso não funcionar nas suas circunstâncias, você também pode considerar carregar seu estado de instantâneos (você ainda tem um histórico de eventos muito longo, mas isso não importa, porque esses eventos foram recolhidos por trás do instantâneo recente).
Outra alternativa é simplesmente reparar o fluxo de eventos; elide os eventos gerados pelo ataque, gere novos números de sequência para o resto, substitua. Se o problema é raro e barato de consertar, é perfeitamente razoável que a empresa decida que soluções complicadas para evitar o problema não são uma prioridade.