Domain Driven Design é uma expressão de modelagem e arquitetura de dados. Você organiza o seu sistema com base em conceitos de domínio e, partir deles, desenvolve seus casos de uso.

Aliás, não existe autenticação com JWT. O padrão JWT é stateless, ou seja, ele guarda uma informação e passa a substituir uma outra. Enquanto ele for válido, a informação contida nele também será. Isso é a referência direta ao sistema de autorização. A autorização nada mais é do que, em referência ao mundo real, uma procuração. Qualquer um com esse "papel" faz o que quiser em seu nome desde que o papel seja válido. Enquanto alguém tiver posse desse papel, acabou, não precisa mais de você.

Esse erro foi muito impulsionado pela geração de cursinhos de programação e uma falta de leitura e bons estudos. Muitos vídeos e conteúdo, aqui, no Youtube e até no Medium, confudem constantemente o conceito.

Autenticação é quando suas credenciais são utilizadas para montar uma sessão que pode ser controlada. Quando você faz entra em um aplicativo, você está se autenticando e tem uma sessão persistente no back-end, geralmente pela troca de cookies. É quando você consegue entrar no app e clicar em "Sair desse dispositivo".

Dado isso, você não autentica um usuário com JWT, você autoriza ele a acessar partes do sistema por um tempo limitado. Em algum momento esse token deverá ser regenerado por razões de segurança e se você precisar trocar a sua senha, por exemplo, o sistema vai pedir para você se autenticar novamente, uma vez que o JWT é impessoal.

JWT's são muito úteis para APIs. Por exemplo, se você quer se conhectar a uma API sem precisar consultar o escopo do cliente no banco de dados a cada conexão. Você compartilha o JWT e baseia todas as restrições de acesso nele, confiando plenamente que aquele é o usuário porque aquele token existe e ele é válido.

Recentemente, precisei emitir relatórios em um sistema. Esses relatórios tinham uma expiração curta e era obrigatório um input de entrada para gerar esse relatório. Nesse caso, JWT se aplica bem, a partir do input de entrada gero o JWT e enquanto o token estiver vivo o relatório será lido. Nem preciso consultar se a pessoa que está usando o token é mesmo quem diz ser, porque se o token for válido, foi emitido e se emitido o relatório pode ser visto. Isso é stateless.

Agora voltando para sua dúvida original. Você tem níveis diferentes camadas de serviços. No domínio de usuário você terá os serviços de emissão autenticação ou autorização recebendo um input de entrada e retornando uma saída. Quando você ler esse token em outro domínio, você irá ter outro serviço de leitura de autenticação ou autorização referente aquele domínio.

No serviço do usuário ficam as regras de negócio de validação do input, garantia que existência do usuário, etc, e a conversão desses dados para um outro dado que represente esse usuário: pode ser um token de sessão (no caso de autenticação) ou um JWT (no caso de autorização). Do outro lado, no servido de pedidos, por exemplo, você irá interpretar o valor de autenticação ou autorização recebidos e ver se essa identificação pode ler os pedidos ou quais ela está autorizada a ler.

Domain-Driven Design é uma coisa bem complexa e leva tempo para aprender, recomendo a leitura do livro Domain-Driven Design: Atacando as Complexidades no Coração do Software. Tem que ler umas três vezes, mas você aprende. Sugiro, entretanto, não implementar em um projeto real sem ter o domínio completo, pois você pode deixar mais complexo do que realmente é.