é máquina de estado adequado para lidar com mudanças de estado no sistema de promoção de vendas?

Question

Estou desenvolvendo sistema de promoção de vendas e eu pisei em algo que poderia ser provavelmente manipulados com padrão de máquina de estado, mas não tenho experiências com máquinas de estado ainda. Talvez a máquina do Estado é totalmente inútil nesta situação :) Então, eu tenho uma promoção de vendas que tem alguma duração, alguns atribuídos clientes, produtos, descontos etc. Cada promoção também tem o seu estado. Há cerca de 5 estados. As transições entre os estados estão estritamente definidos - não é possível alterar o estado 1 para o estado 3 diretamente - usuário tem que mudam de estado para 2 pela primeira vez. Há algumas limitações, como "não é possível adicionar mais produtos, quando a promoção está em estado de 3-5". Ou limitações como "única super-usuários podem editar os custos de promoção quando está no estado de 3-5".

Acabei de ler sobre http://www.codeplex.com/SimpleStateMachine , mas eu' não tenho certeza se não é demasiado complexo para este caso. Eu poderia lidar com a lógica estado na minha camada de serviço usando coisas como:

if (promotion.state == statesRepository.GetState3() && false == loggedUser.IsInRole("superUser")){
   throw new PromotionStateException("user not allowed to edit promotion in this status");
}
...

ou

public void ChangePromotionStatus(promotion, newStatus){
  if (promotion.Status == status1 && newStatus != statesRepo.GetState2()){
    throw new StateTransitionException("unable to change from status 1 to " + newStatus);
  }
}

Mas eu não gosto deste tipo de código - deve haver alguma abordagem melhor :) alguém tem um conselho? Eu poderia separar as preocupações de curso e desenvolver serviços como PromotionStatusChangeReviewService, PromotionEditPermissionService etc para tornar o código menos acopladas, mas provavelmente há alguma solução melhor eu não posso ver no momento.

Answer 1

Cinco estados não é muito complexo para uma máquina de estado, mas eu acho que você está correndo em alguns problemas ao tentar fazer algumas das transições ser tratados de forma especial ou explicitamente. Aqui estão algumas dicas:

• As máquinas de estado não são úteis a menos que você pode rotular os estados de uma forma significativa. "Status de 3" não significa nada; você precisa chamá-lo de algo útil como "promovido", "Ativo", "Concluído", et cetera.

• Parte do padrão de Máquinas de Estado pressupõe que você tenha uma entidade separada que compreende os estados e como fazer a transição entre eles. Você não deve ter um método como o ChangePromotionStatus() no seu exemplo, por exemplo, onde ele explode se o Estado não deve ser permitido. A máquina de estado deve simplesmente evitar transições que não pode ocorrer.

• Se o número de possíveis transições é pequeno e bem definido, e faz sentido classificá-los, eu também recomendo nomear as transições bem. Este é provavelmente especialmente útil se as transições todos fazem a mesma coisa, mas de forma ligeiramente diferente.

Answer 2

John bateu o prego na cabeça - você quer que seu processo, como modelado usando uma máquina de estado, a ser dissociado de suas entidades de domínio. Suas entidades de domínio provavelmente não deve ter conhecimento direto de que eles estão sendo usados ??em uma máquina de estado, que irá gerenciar o trabalho de transição-los de estado para estado baseado em determinados eventos, mas eles irá o entendimento do negócio significado de cada estado em que estão, e ser capaz de cumprir ou aplicar regras de negócio relacionadas com esses estados.

O ideal é que suas entidades de domínio que são apropriados para ser gerida por uma máquina de estado terá algum tipo de status que atua como um estado da máquina de estado, e vai elevar eventos que podem ser usadas pela máquina de estado para determinar quando um transição é apropriado.

No entanto, se é verdade que os estados são completamente seqüencial - ou seja, eles sempre ir abcde ou para trás e para a frente exatamente um passo, eu não tenho certeza de uma máquina de estado faz sentido porque não há há contexto especial necessário para escolher o próximo estado - você só pode ir para trás ou para a frente, de modo que qualquer lista ordenada de estados (como um Enum) juntamente com Next / lógica anterior deve ser suficiente - mas os processos do mundo real raramente são que estritamente linear, mesmo que possa parecer à primeira vista.