Tenho que estender um aplicativo de gerenciamento de casos .Net 4/C# que usa o Oracle 11g para lidar com casos legais.
Tenho um orçamento mÃnimo, minha experiência com Oracle e um desenvolvedor C# muito júnior para fazer isso. O módulo adicional será utilizado por no máximo 20 pessoas em uma intranet.
As regras existentes são geralmente assim:
- para completar uma ação deve haver propriedade a, propriedade b, propriedade c presente em uma tabela com uma relação claramente definida com a tabela onde a nova inserção deve ser validada
- Para casos legais, novas regras de negócios são mais como "tudo é uma exceção" Mais formalmente reformulado, pois as entradas de dados em outras tabelas podem ou não afetar o resultado de transações futuras com base em condições desconhecidas
O aplicativo existente usa o Microsoft Workflow para implementar as regras de negócios. Isso provou ser pesado, quase inutilizável para nós. Drools e seus equivalentes comerciais são igualmente complicados e não atingirão o objetivo de permitir que os gerentes entendam sua lógica de negócios.
- seria um benefÃcio se a lógica de negócios pudesse ser vista pelos usuários em um relatório sem a necessidade de ler comentários ou código C#.
- a lógica pode ser adicionada ou desabilitada rapidamente sem desativar o aplicativo da web
- bastante fácil de implementar, dado que temos orçamento limitado e conjuntos de habilidades
Isso me traz à velha ideia de manter a lógica de negócios no banco de dados como uma série de tabelas de decisão. Isso ainda é feito ou tem a ideia de que a eficiência de manter a lógica de negócios no aplicativo é obviamente melhor?
Editar: o fluxo de trabalho é implementado como um serviço. Meu entendimento é que ele visava fluxos de trabalho de longa duração. No nosso caso, os usuários pressionam o botão salvar e o fluxo de trabalho é executado. Nossos problemas são
- dolorosamente lento para desenvolver em nossas máquinas, congela, trava
- difÃcil de depurar
- de vez em quando o gerenciador de fluxo de trabalho lança erros por algumas horas sem motivo que possamos encontrar
- toque em um fluxo de trabalho e você terá que alterar 14 outros arquivos
- o aplicativo é lento para os usuários, parte dos quais rastreamos os fluxos de trabalho.
A validação no banco de dados começa a parecer boa porque a validação é toda baseada nos dados do banco de dados.
@catcall Existem 10 ou 12 advogados que não usam o aplicativo, mas têm 8 ou 10 administradores para fazer a entrada de dados.
Acabamos de atualizar o desktop, mas o chefe não acredita que os programadores contratados devam ter equipamentos melhores do que funcionários. Portanto, o Windows XP com 4 núcleos e 3 GB de RAM é o melhor que podemos fazer. Investigarei se existe alguma classificação de tipos de lógica de negócios. Algumas delas podem ser feitas de forma mais eficiente no aplicativo. Outros tipos podem ser alterados e configurados com mais facilidade no lado do banco de dados.
"Pessoas" é um termo confuso quando você está falando sobre aplicações legais. Apoiar 20 advogados é muito diferente de apoiar 1 advogado, 4 paralegais e 15 funcionários.
E esse é um dos motivos. No gerenciamento de casos, certos tipos de coisas são simplesmente determinÃsticos. Momento das respostas, prazos para arquivamento, coisas assim. Mas as regras que regem foram escritas por advogados para advogados. As empresas que constroem software de gerenciamento de casos têm advogados na equipe para ler as regras de procedimento (que mudam com o tempo) e para verificar se seu software está em conformidade com as regras.
Alguns deles têm muitos advogados.
Outros tipos de coisas são governados pelo capricho. Por exemplo, alguns pacotes de gerenciamento de casos permitem que os usuários "modelem" suas tarefas. Inserir algo como "Depósito" no calendário também pode agendar uma série de tarefas anteriores que devem ser feitas para se preparar para o depoimento. Sob a pressão de prazos múltiplos e incompatÃveis, partes de uma cadeia de tarefas são descartadas ou recebem pouca atenção.
Agora, para (finalmente) chegar à sua pergunta. . .
As tabelas de decisão no banco de dados são uma solução viável. Na verdade, as tabelas de decisão constituem um banco de dados, estejam elas armazenadas no Oracle ou no código do aplicativo. Existem compensações óbvias para armazenar tabelas de decisão no código do aplicativo.
Mas as tabelas de decisão no banco de dados provavelmente não são uma solução viável para você. O problema que você tem, se bem entendi, é que você acha que pode precisar simplificar a arquitetura das tabelas de decisão para eliminar (ou pelo menos reduzir bastante) o uso do Microsoft Workflow. Com apenas dois de vocês e um orçamento mÃnimo, o sucesso será difÃcil na melhor das hipóteses.
Posso sugerir duas coisas.