Carregando Post...

Do design orientado por domínio para microservices

Como a filosofia de desenvolvimento de design orientada por domínio pode ser adaptada aos microservices

 

Como muitos de vocês podem se lembrar, o design de software e o estilo de arquitetura conhecido como arquitetura orientada a serviços (SOA) surgiram em meados da década de 1990. Desde então, descobrimos melhores maneiras de construir sistemas, incluindo avanços na virtualização baseada em nuvem, integração contínua e entrega, e microservices. No processo, essas tecnologias tornaram a SOA e todos os benefícios associados uma realidade.

Em novembro, procurei explicar como os microservices podem ser introduzidos em uma grande organização com sistemas herdados bem estabelecidos . Nesta publicação, eu cubro o design orientado por domínio (DDD) e como esta filosofia de desenvolvimento pode ser usada para representar o mundo real em código, sendo bem adaptada a uma implementação de microservices.

Design orientado por domínio

A coesão é um princípio precoce de design de software e refere-se ao grau de relação funcional que existe dentro de um módulo ou classe. Neste contexto, a coesão foi descrita pela primeira vez no final da década de 1970 por Tom DeMarco e passou a significar agrupar e manter as coisas que mudam pelos mesmos motivos e separar a funcionalidade que muda por diferentes motivos. 

DDD fornece uma via para facilitar o desenvolvimento de sistemas altamente coesivos através de contextos limitados. O Microservices é uma abordagem de implementação que incentiva você a concentrar seus limites de serviço nos limites do domínio de negócios. DDD e microservices podem ser usados ​​juntos enquanto você move sua organização para um design orientado para serviços e colhe os benefícios da integração e entrega contínuas.

O trabalho seminal em DDD foi definido em um livro de 2003 de Eric Evans chamado Domain-Driven Design: Tackling Complexity in the Heart of Software . A filosofia geral do DDD é usar a noção de contextos delimitados que formam camadas de proteção em torno de modelos que definem o domínio comercial. Os contextos limitados são análogos aos departamentos de uma empresa - o departamento jurídico tem certas responsabilidades específicas (contextos) diferentes do departamento de TI e essas responsabilidades são aplicadas por regras (limites) para interação e obtenção de serviços dos departamentos. 

Isso é o mesmo para contextos delimitados que você usa usando DDD. Para facilitar uma compreensão comum do domínio do problema e traduzir esse conhecimento de domínio em um sistema informático, a equipe comercial e técnica deve desenvolver um idioma comum. Em DDD, esse idioma comum é chamado de linguagem onipresente (UL). À medida que a equipe técnica desenvolve seus modelos e códigos, ele usa a UL para diminuir o risco de incompreensão entre os analistas de negócios e a equipe de engenharia à medida que o projeto avança. 

Isso também serve para fornecer uma camada adicional de documentação dos sistemas e melhora a compreensão da organização de como um sistema foi projetado e destinado a funcionar. Os modelos de análise que são usados ​​para entender e definir o domínio estão ligados aos modelos de código que são usados ​​para criar software pela UL.

Outros princípios fundamentais da DDD incluem:

 

2018 é o ano do seguro de dados?

Do processamento de linguagem natural para estratégias de multi-nuvem, 2018 está se formando para ser um grande para inteligência de negócios. Leia este relatório gratuito para aprender as principais tendências em BI em 2018.

·         Criação iterativa dos modelos de análise e código. À medida que a equipe aprende mais sobre o domai, ele itera em seus modelos de análise e código, mantendo ambos sincronizados. O DDD não especifica ferramentas, bancos de dados ou idiomas, mas usei UML (Universal Modeling Language) para criar modelos de análise e meus modelos de código ou implementação foram feitos em C ++ e Java.

·         A colaboração das equipas técnicas e de negócios exige uma colaboração estreita e presencial para criar os modelos relevantes. Este é um forte compromisso para todas as partes desenvolverem a UL, usá-la para definir o domínio, iterar através da definição do domínio e focar o problema em vez de saltar diretamente para uma solução.

·         Concentre-se nos domínios principais. Os domínios principais são os domínios que tornarão o produto um sucesso. É um domínio central se é absolutamente essencial para o sucesso do negócio. Você deve estar se perguntando como esse domínio aumenta as receitas, reduz custos ou aumenta a eficiência, e por que e como este domínio é fundamental para o negócio.

·         O problema que você está resolvendo deve ser substancial. Não há nenhum uso na implementação do DDD para problemas que são insignificantes, não moverá a agulha para o negócio, ou será melhor resolvido com uma solução comercial off-the-shelf.

Depois de ter começado a entender o problema do negócio e desenvolver modelos para defini-lo, você terá que pensar sobre como integrar contextos limitados. Em seu livro Enterprise Integration Patterns (Addison Wesley Signature Series), Gregor Hohpe e Bobby Woolf definem quatro estilos de integração: transferência de arquivos, banco de dados compartilhado, invocação de procedimento remoto e mensagens. Na maioria das aplicações de tamanho substancial e por razões de coesão, o DDD e a equipe técnica provavelmente se estabelecerão na invocação do procedimento remoto e / ou mensagens para integração.

Do design orientado por domínio para os microservices, combinar essas duas abordagens para resolver problemas grandes e complexos faz sentido comercial.

Comentários

Deixe um Comentário

Posts Recentes

20/Dezembro/2017

Seis maneiras fáceis de...

20/Dezembro/2017

Do design orientado por...

20/Dezembro/2017

Em um mundo de IA...

Categorias


Onde Proeminente Sistemas está? clique no mapaFechar Mapa

Entre em Contato com a Proeminente Sistemas

Escreva para Proeminente Sistemas para trocar algumas ideias!

Telefone

(24) 9972-6790

Email

proeminente@proeminente.com.br

Localização

Rio de Janeiro