Como gerenciar threads em segundo plano e reportar progresso com DDD

5

O título diz a maior parte. Eu encontrei poucas informações surpreendentes sobre isso. Eu tenho uma operação longa em que o usuário quer ver o progresso (como no item x de y processado). Eu também preciso ser capaz de pausar e interromper a operação. (Parar não reverte os itens já processados.)

A coisa é, não é que cada item demore muito para ser processado, é que normalmente há muitos itens. E o que eu li até agora é que é um pouco anti-padrão para colocar algo como uma fila no banco de dados. Atualmente, não tenho nenhum sistema de mensagens em funcionamento e nunca trabalhei com nenhum deles.

Outra coisa que li em algum lugar é que o relatório de progresso é algo que pertence à camada de aplicativo, mas não entrou nos detalhes. Então, tendo dito tudo isso, o que tenho em mente é o seguinte.

  • Solicitação de usuário com lista de itens entra na camada do aplicativo.
  • A camada de aplicação obtém algumas informações do domínio necessário para processar os itens.
  • A camada de aplicação transfere os itens e as informações para algum serviço de domínio (a implementação deste serviço deve pertencer à camada de infraestrutura?)
  • Esse serviço gera um segmento de trabalho com retornos de chamada para os relatórios de andamento e pausando / parando.
  • Este segmento de trabalho processará cada item em seu próprio UoW. Isso significa que as informações de domínio anteriores precisam ser armazenadas em algum DTO.
  • Como nada é realmente persistente, o serviço deve ser singleton e thread safe
  • Sempre que um usuário solicitar um relatório de andamento ou quiser pausar / interromper a operação, a camada do aplicativo perguntará ao serviço.

Esta seria uma solução correta? Ou estou pelo menos no caminho certo com isso? Especialmente a parte segura singleton e thread faz a coisa toda sentir nojento.

    
por dvdvorle 12.10.2012 / 08:23
fonte

1 resposta

1

Estes tipos de preocupações operacionais são da responsabilidade da camada de aplicação e, como tal, são agnósticos do DDD. A camada de aplicação delega na camada de domínio que pode ser implementada usando DDD. É atípico para um serviço de domínio criar segmentos de trabalho e lidar com o status de processamento. Em vez disso, ele deve ser focado na implementação de lógica de domínio que não pertença naturalmente a um objeto de agregação, entidade ou valor. O gerenciamento de encadeamentos e o status de processamento devem ser tratados pela camada de aplicativos, pois é uma preocupação operacional, não uma preocupação de domínio. Existem várias maneiras de implementar processos de execução longa com informações de progresso. O uso de threads em um AppDomain é apenas um caminho a ser seguido. Por exemplo, se a tolerância a falhas e a distribuição forem necessárias, é melhor colocar itens de trabalho em uma fila durável e ter um manipulador de mensagens que processe essas mensagens, delegando à camada de domínio. Essa implementação é descrita em Request / Acknowledge / Poll Com ASP.NET WebAPI e NServiceBus . Independentemente da implementação dessa responsabilidade da camada de aplicativos, o domínio permanece o mesmo.

    
por 13.10.2012 / 19:35
fonte