Adiministração

Design Pattern Facade
Uma vez que um pedido de exame pode ser solicitado para uma grande variedade de operadoras de saúde, existirão diferentes regras aplicadas para a liberação das autorizações. E por mais que o negócio seja o mesmo, cada operadora possuirá em seus sistemas/serviços de autorização uma implementação diferente para as mesmas operações.
Desta forma, para tornar mais fácil a utilização destas regras necessárias para a autorização, o padrão Facade deve ser aplicado. Assim conseguiremos prover uma interface única e simplificada para realizar as operações junto às operadoras de saúde.

Design Pattern Singleton
Como se trata de um serviço com onde qualquer tipo de informação incorreta ou algum tipo de fraude pode ocasionar sérios problemas judiciais, faz-se necessário a utilização de logs dos eventos ocorridos durante todo o ciclo de uma solicitação de autorização. O padrão, apesar de ser considerado anti-pattern por alguns desenvolvedores, fornece o que precisamos para implentar o log em todo o serviço.

Design Pattern Composite (?? Fiquei na dúvida pra explicar esse apesar de achar que não precisa explicar muito, rs)
O sistema foi baseado em Pedidos e Procedimentos. A estrutura destes elementos define que um pedido possui vários procedimentos.
Cada procedimento adicionado ao pedido recebe o status inicial “Aberto”.

Design Pattern Observer e State (são parecidos, não sei qual seria)
Aqui é uma dúvida: não sei se o objetivo destes padrões está alinhado ao que eu imaginei. Como eles são responsáveis por notificar os observadores (imaginei a classe Pedido), entendi que em qualquer alteração do status do procedimento o pedido que está associado deveria ser notificado.
Seria isso?