Uma express ao modelo de dados é definido na Empresa Integração de Padrões como a solução para minimizar dependências para a integração de aplicativos que utilizam diferentes formatos de dados. Por outras palavras, Um componente (uma aplicação ou um serviço) deve comunicar com outro componente através de um formato de dados que seja independente de ambos os formatos de dados.
duas coisas a destacar aqui. Primeiro, defini um componente como uma aplicação ou um serviço porque tais modelos são / foram utilizados no contexto da integração de aplicações e orientação de serviços. Em segundo lugar, estamos a falar de um conceito que deve ser utilizado apenas como formato de dados de transporte. Você não deve usar um formato canônico de dados como a estrutura interna do seu armazenamento de dados.Teoricamente, as vantagens são bastante óbvias. Um formato canônico de dados reduz o acoplamento entre aplicações, reduz o número de traduções a serem desenvolvidas para integrar um conjunto de componentes, etc. Muito interessante, não é? Um único modelo de dados é compreensível por toda a paisagem de TI e um conjunto de pessoas (desenvolvedores, analistas de sistemas, stakeholders de negócios, etc.) que podem partilhar a mesma visão de um determinado conceito.
para fins práticos, a implementação de tais modelos raramente é eficiente.
uma pessoa não é o mesmo conceito para o departamento de marketing e apoio de uma companhia de seguros. Um voo para um sistema de gestão do tráfego aéreo tem um significado diferente, dependendo se foi preenchido por um piloto ou se é um voo em curso no topo do seu espaço aéreo. Uma parte PLM tem uma representação completamente diferente dependendo se ela foi projetada ou se ela tem que ser mantida por uma equipe de suporte.
Na maioria dos contextos, a concepção de um modelo de dados canônico resulta em um grande modelo de dados com um conjunto completo de atributos opcionais e muito poucos obrigatório (como os identificadores). Apesar de ter sido projetado principalmente para facilitar a integração de componentes, você vai apenas complicá-lo. Entretanto, o seu modelo irá criar uma grande frustração entre os utilizadores devido à sua complexidade inerente (em termos de utilização e gestão). Além disso, no que se refere à questão do acoplamento, está apenas a deslocá-lo para outro lugar. Em vez de ser acoplado a um formato de dados componente, você se torna fortemente acoplado a um formato de dados comum que será usado por toda a paisagem de TI e sujeito a mudanças muito frequentes.
in a nutshell, in most of the contexts, a canonical data model should be considered as an anti-pattern. Qual é a outra opção do que considerar que você ainda deve querer minimizar as dependências entre dois componentes trocando dados?
Domain Driven Design (DDD) recomenda a introdução do conceito de contexto limitado. Um contexto limitado é simplesmente um contexto explícito no qual um modelo se aplica com limites claros com outros contextos limitados. Dependendo de sua organização, um contexto limitado pode se referir a um domínio funcional no qual um objeto é utilizado, ele pode se referir ao próprio estado do objeto, etc.
nesse caso, o modelo de dados canônicos como tal seria simplesmente a parte amarela no diagrama seguinte.:
A intersecção de A, B e C representa o conjunto de atributos que deve haver independentemente do contexto (basicamente os atributos obrigatórios do antigo grande MDL). Esta parte deve ainda ser cuidadosamente concebida devido ao seu papel central. No entanto, é importante mantermo-nos pragmáticos. Se em seu contexto não faz sentido ter um modelo comum, você deve simplesmente descartá-lo.
o que também é importante é uma intersecção entre dois contextos (A E B, B E C, C e A). Como mapear uma representação de um objeto de um contexto para outro? Quais são os atributos explícitos que devem ser compartilhados em dois contextos? Quais são as restrições comerciais comuns entre dois contextos? Estas questões ainda devem ser respondidas por uma equipe transversal, mas de uma perspectiva de negócios, faz sentido levantá-las. Nem sempre foi o caso de um único MDL partilhado em contextos potencialmente opostos.No entanto, no que diz respeito às partes que não são partilhadas com outros contextos (em branco), não deve fazer parte de um modelo de dados da empresa. Devias ser pragmática. Por exemplo, se um subconjunto é específico de um determinado domínio, deve ser até o domínio especialistas para modelá-lo eles mesmos.
Um desafio importante, porém, é identificar os contextos limitados e que poderia ser a pena lembrar aqui a Conway, da lei:
Qualquer organização que desenvolve um sistema, inevitavelmente, produzir um projeto cuja estrutura é uma cópia da organização da estrutura de comunicação.
os contextos limitados não devem ser necessariamente mapeados na organização atual. Por exemplo, um contexto limitado pode abranger vários departamentos. Quebrar silos organizacionais ainda deve ser um objetivo para a maioria das empresas.
além disso, DDD introduz o conceito de camada Anticorrupção (ACL). Este padrão pode se referir a uma solução para uma migração legada (introduzindo uma camada de intermediação entre o antigo e o novo sistema para evitar problemas de qualidade de dados, etc.). Mas em nosso contexto, quando falamos de corrupção, ela está relacionada com a modelagem de dados dívida que você pode introduzir para resolver problemas de curto prazo.
tomemos o exemplo de dois sistemas encarregada de gerenciar um determinado estado de uma PLM parte (uma parte é um item físico produzido ou adquirido e, em seguida, montado como um rotor de helicóptero, por exemplo). Um sistema legado (vamos chamá-lo de SystemA) é encarregada de gerenciar a fase de projeto, você deve implementar um novo sistema (vamos chamá-lo de SystemZ) encarregada de gerenciar a fase de manutenção. Toda a paisagem de aplicações de TI compartilha o mesmo identificador de parte comum (partId), exceto para SystemA que não tem conhecimento dele. Em vez do partId, o SystemA gere o seu próprio identificador, o systemAId. Como SystemZ precisa ser call SystemA usando systemAId, uma heurística pode ser integrar systemAId como parte do modelo de dados SystemZ.Este é um erro comum que deve evitar. Você simplesmente corrompeu seu modelo de dados por causa de uma situação de curto prazo.
o padrão ACL poderia ter sido uma solução aqui. SystemZ poderia ter implementado seu próprio formato de dados (sem qualquer corrupção externa como o systemAId). Em seguida, teria sido até uma camada intermediação para gerenciar a tradução entre o partId eo systemAId.
aplicado ao nosso tópico, o padrão ACL obriga a implementar uma camada entre dois contextos delimitados diferentes. Um componente não está ciente de como chamar outro componente que não faz parte de seu próprio contexto limitado. Em vez disso, um componente só está ciente de como mapear sua própria estrutura de dados no formato de dados do contexto delimitado a que pertence.A propósito, esta é uma regra de ouro. Um componente deve pertencer a apenas um contexto limitado. É também por isso que DDD é um grande ajuste para a arquitetura microservices. Devido à granularidade fina, é mais fácil cumprir esta regra.
resumindo, um modelo canônico como tal deve ser considerado como um anti-padrão na maioria dos casos. Você deve tentar implementar o conceito de contexto limitado que significa um modelo por contexto com fronteiras explícitas entre os contextos. Dois componentes que são parte de diferentes contextos limitados devem se comunicar através de uma camada Anti-Corrupção para prevenir a corrupção modelagem de dados.