Análise de portabilidade para migrar para o .NET Core

Já estamos próximos da versão 2.0 do .NET Core. Se você ainda está na versão Full (.NET Framework 4.x), já é hora de começar a pensar em uma migração. Talvez não para agora, mas é importante preparar um planejamento para 1 ou 2 anos, para essa migração.

A Microsoft disponibiliza uma ferramenta interessante para essa tarefa. É o .NET Portability Analyser. 

É uma extensão do visual studio que você pode usar na versão 2015 ou 2017. Depois de instalado, você pode configurá-lo através do menu Analyze > Portability Analyzer Settings.

Nesse exemplo eu vou analisar a compatibilidade dos meus projetos com o .NET Core 2.0 e o .NET Standard 2.0.

Para fazer a análise, clique com o botão direito sobre a sua solution (ou projeto se preferir), e escolha a opção Analyze Assembly Portability.

Ao término, a seguinte janela irá aparecer, a partir da qual você poderá acessar o relatório da analise realizada. Note que nesse exemplo eu optei por gerar um relatório em Excel.

Na primeira planilha desse arquivo você vai encontrar um resumo indicando o % de portabilidade de cada um dos projetos da sua solução, para os Targets selecionados.

Na segunda planilha do arquivo você encontrará uma lista detalhada de todas as incompatibilidades encontradas. Note que você poderá filtrar por projeto, e que em alguns casos já existe uma orientação do que você deve fazer para conseguir portar para o target desejado.

E por fim, na terceira planilha do arquivo você pode ver a lista de assemblies que está utilizando, e que ainda não estão na API do .NET Portability Analyser, e portanto ainda não existe uma análise com relação à essas bibliotecas:

Essa ferramenta será muito útil no processo que você irá enfrentar ao migrar suas aplicações para o .NET Core.

DDD - A Grande Bola de Lama

Anterior

Se você observar o Mapa do DDD, na parte mais abaixo, irá notar que um dos elementos é chamado de Big Ball of Mud, ou a Grande Bola de Lama. 

No mapa esse elemento aparece para ilustrar a ideia de que um Mapa de Contexto bem feito, serve para organizar a bagunça que podemos ter em domínios que contém uma grande quantidade de conceitos.

Mas afinal, o que é a Grande Bola de Lama?

Aposto que você já se deparou com ela em algum projeto por aí. Eu já encontrei várias, e algumas delas produzidas por mim mesmo. 

Um dos lugares mais fáceis de se ver uma bola de lama é em um diagrama de Entidades e Relacionamentos, muito comum nos anos 90 e início dos anos 2000.

Mas o habitat natural dessas bolas continua sendo o código mesmo, onde elas são mais comumente conhecidas como código espaguete. Veja abaixo uma de suas manifestações:

Mas a razão para a grande bola de lama aparecer no mapa, é que um dos principais motivos do DDD é justamente evitá-las em nosso projeto, sejam elas grandes ou pequenas.

DDD - O Mapa

Anterior

O Evans em seu livro, sugere esse mapa para demonstrar e explicar os principais elementos do DDD. Podemos dividir esse mapa em duas partes para entendê-lo melhor. Para isso, parta do elemento Model-Driven Desing e divida o mapa em duas partes: os elementos abaixo do model-driven design, e os elementos à cima.

Na parte de baixo do mapa, temos os elementos mais arquiteturais do DDD. Em DDD nós basicamente partimos de um Domínio, que é divido em Subdomínios, que serão implementados individualmente através de um Bounded Context. Teremos alguns Subdomínios especiais, como o Core Domain e o Shared Kernel. E tudo isso deve ser organizado através de um Mapa de Contexto, e sempre respeitando a tal da linguagem ubíqua (ou onipresente).

Na parte de cima temos os principais elementos e padrões utilizados na modelagem de um domínio. São as práticas mais próximas do nosso código. Através de uma arquitetura de camadas, modelamos nosso domínio com o uso de Entidades, Objetos de Valor e Agregações. Armazenamos e recuperamos dados através de Repositórios, e implementamos nossas regras de negócio com o uso de Serviços, Factories e Eventos.

Esse Mapa serve como um guia, e nos ajuda a entender como todos os conceitos sugeridos pelo DDD se relacionam. Cada um desses elementos é um capítulo à parte no DDD, e aos poucos pretendo abordá-los aqui nesse blog.

Próximo