Sinceramente, se você tem 40 tabelas realmente idênticas eu não entendo o motivo da concepção desses 2 sistemas serem dessa forma, ao invés de pensar numa alternativa naquela linha que mencionei anteriormente.
Em todo caso, pense nos problemas que criar esse JAR compartilhado poderá te causar. Sempre que um dos sistemas precisar mudar uma classe você vai ter que executar testes em ambos pra ter certeza que a mudança não quebrou alguma coisa no outro sistema.
Uma coisa perigosa de acontecer é: você ficar mudando o JAR e só atualiza-lo no sistema demandante da alteração. Depois de muito tempo, quando o outro sistema precisar demandar alguma alteração e for pegar o JAR atualizado, isso pode causar problema. Você pode também descobrir que uma demanda de um sistema é conflitante de alguma forma com alguma outra que foi gerada pelo outro sistema um tempo atrás.
Eai
Estou sem muito tempo para postar, mas dá uma pesquisada em BondedContext, ContextMap e Shared Kernel que são patterns do DDD. A sua situação me parece um shared kernel.
[]s
Eu pensava que Shared Kernel fosse dentro do mesmo Sistema/Domínio, compartilhando objetos entre módulos. Nunca pensei nisso aplicado a mais de um sistema. Talvez seja uma opção, não sei.
Eu prefiro optar por pensar em 2 sistemas cada um tendo seu Domínio e se comunicarem via serviços.
Especificamente no caso do nosso amigo, está claro que esses 2 sistemas deveriam trocar mensagens, mas por algum motivo que eu ainda não consegui entender, uma aplicação não pode conversar com a outra.
Emerson,
Talvez vc tenha razão… Acho que uma coisa que ajudaria a esclarecer é pensar se realmente são dois sistemas! porque se grande parte do domino é comum, isso nao poderia ser um sistema só, com um shared Kernel e 2 Contextos e duas camadas de visualização?
Então, se você der uma lida no meu primeiro post, vai ver que eu sugeri 2 UIs. Claro que internamente podemos ter um Shared Kernel, 2 contextos, etc. Mas como ele disse que não pode ter 2 UIs pra mesma coisa e que os sistemas não se comunicam de forma alguma, ficou algo meio como que um beco sem saída porque (1) Um dos sistemas roda na Web online e outro é um Desktop off-line e (2) um sistema não pode se comunicar com o outro sei lá o motivo e (3) pelo visto cada um tem sua base de dados independente.
Os dois sistemas, são independentes, mas possuem similaridades (que é a grande parte do modelo de dados, das tabelas de apoio, mas cada um tem a sua base independente), um é web e outro é desktop (off-line durante a operação toda do usuario, sendo que somente no final do dia ou sei lá quando, é que ele utilizará um web-service ou algum outro protocolo para enviar os dados das declarações nele feitas para um terceiro sistema que recebe tais declarações).
Ou seja, tenho um sistema web que gera, outro desktop que declara. Este dois sistemas são independentes, tem suas proprias bases de dados tem finalidades diferentes apesar de terem regras comuns como calculo de imposto e outras coisas, mas o que eles tem de mais comum é a estrutura da base de dados, quase todas as tabelas de apoio se assemelham, entao minha duvida era se compensava ou não criar um projeto em separado que modelasse o modelo de dominio de ambos ou pelo menos essa parte em comum para que eu tivesse um reaproveitamento.
No entanto, percebo que isto irá me causar mais problemas do que facilidades, o que eu posso fazer é estar componentizando algumas regras de negocio em comum como o calculo de impostos, mas sem utilizar objetos de dominio nisto, visto que cada um teria suas proprias classes, ou seja, o modelo de dominio (tbem de mapeamento objeto - relacional) nao poderá ser compartilhado e sim construido de forma independente.
Pergunta: Os sistemas tem que ser dessa forma por imposição de alguém ou vocês que escolheram assim?
Pra mim isso ta meio mau pensado …
Se você tem 2 sistemas que tem uma area de interesse um pouco comum e que você tem que duplicar 40 tabelas, isso não te parece estranho?
O sistema tem de ser assim, um web que atende determinado tipo de usuario e tem uma finalidade propria (geracao de nfse) e outro desktop que atende outro tipo de usuario que nem sempre tem acesso a internet e com outra finalidade (declaração de nfse recebida e gerada)
[quote=spranta]Pessoal, estou participando de um projeto que possui vários sistemas com alguns pontos relacionados.
Explicando melhor, tenho um sistema de emissao de Nota Fiscal e outra de Declaração de Notas. Esses dois sistemas tem quase todo o modelo de dados identico, mas existem algumas diferenças, e algumas funcionalidades de um sistema servem para o outro.
Enfim, a intenção do gestor do projeto é que o modelo de classes destes dois sistema sejam compartilhados, desta forma, nós teriamos um projeto em separado só com as classes de dominio que modelam um contexto unico mas que engloba as situações dos dois sistemas e para tanto, na aplicação web de ambos os sistemas existirá um jar que representa esse conjunto de classes de dominio compartilhados por ambos os sistemas.
Na pratica tudo parece lindo, ou seja, eu teria em um projeto separado por exemplo, a classe NotaFiscal, que teria regras de negocio de ambos os sistemas. No entanto, estou com alguns problemas de definição deste modelo integrado de classes. O principal é o hibernate; uso o hibernate e portanto eu espero que as classes do meu modelo de dominio sejam as mesmas classes utilizadas para mapeamento objeto relacional de cada sistema, acontece que como disse anteriormente, apesar da grande semelhança um sistema tem algumas particularidades de outro, como fazer então para que a mesma classe represente mapeamentos diferentes. Se eu tivesse um modelo de dominio unico compartilhado, mas separado das classes de mapeamento do hibernate em que cada sistema teria o seu, seria mais facil, no entanto, acredito que isso nao é o correto.
[/quote]
O modelo de classes dos dois sistemas nao deveriam ser compartilhados, o que deve ser compartilhado é o domínio. Aplicações que manipulam notas fiscais interagem com o dominio onde exista tal conceito. Eu não sei qual a relação sistema <-> domínio vc faz mas em relaçao a dominio <-> database eu penso sempre numa associacao 1 pra 1. E não se deve basear no modelo de dados para definir o que é o dominio, se for pra ser assim esqueca objetos e seja feliz!
Em relação a sua dúvida é difícil pra mim dizer se a diferenca entre os sistemas de emissão e declaracao é de natureza do negócio ou da aplicacao, na dúvida não dividiria o dominio a principio. Da mesma forma poderia sugerir que utilizasse Shared Kernel para compartilhar o dominio mas é possível que a equipe não esteja ciente das implicacoes dessa ato.