terça-feira, 27 de março de 2018

Visão Geral sobre o DDD (Domain Driven Design)

Introdução

Padrões de projetos são excelentes formas de aplicar soluções validadas para problemas conhecidos.
De toda forma, aplicar soluções onde não existe ou existirá o problema, pode gerar um custo grande no desenvolvimento. A arquitetura emergente fala um pouco disso, de entender que a arquitetura é algo que evolui com o sistema, assim como o negócio.
Tenho percebido uma tentativa de aplicação abrangente de padrões para atender o DDD (Domain Driven Desing), com todas as camadas de abstração, em todo e qualquer caso. A dúvida é se o custo x benefício de manter esta abstração desde a concepção do sistema não o torna mais caro do que evoluir ao longo da vida do sistema com refatorações.
Repare, o objetivo não é deixar de ter padrões de projetos, mas sim saber escolher os necessários para cada caso. Assim como o ágil mudou a forma de entregar valor os usuários, ao invés de especificar tudo, codificar tudo, entregar tudo como no waterfall, o mesmo raciocínio se aplica para arquitetura. Deveríamos mesmo fazer a arquitetura completa? Ou ter uma visão de arquitetura completa e deixar o sistema possível de adicionar novas padrões, quando o desafio for encontrado? E entender que eventuais refatorações são necessárias?
Uma coisa é fato, ter um arquiteto fora do time é como ter área de desenvolvimento separada do teste. As pessoas interagem menos, tomam decisões sem pensar no todo e podem ter um custo maior para viabilizar ou manter decisões impostas.

O que não é?

Como disse o Eduardo Pires "O DDD não é uma receita pronta sobre como desenvolver uma arquitetura baseada em Presentation, Services, Application, Domain e Infra." [3]

Quando usar DDD?

Gosto muito deste texto da Graziella Bonizi da Lambda3 "O DDD é voltado para domínios complexos, e depende da quebra de barreiras de comunicação entre especialistas de negócio e especialistas técnicos, além do engajamento do time técnico em programar de forma que o código reflita o domínio. Se uma dessas variáveis for negativa, provavelmente o DDD não serve para o cenário que você está lidando." [1]

Arquitetura Emergente

É importante também perceber que não se deve aplicar o DDD em todas as entidades de um projeto. Deve-se buscar quais as entidades mais importantes para o negócio e entender aquelas mais simples, como um CRUD.
Veja o exemplo abaixo:
Separação de domínio principal, auxiliar - o que será implementado e integrado
Repare que as entidades simples, cadastrais, pode ter uma arquitetura de CRUD muito mais simples que aplicar as camadas do DDD.
Dicas interessantes de um segundo artigo da Graziella da Lambda3 [2]: "princípios utilizados na implementação do sistema Produção:
Começar simples: Você não precisa aplicar todo o conhecimento técnico que você adquiriu na vida ... evitar causar uma complexidade técnica acidental. Um sistema raramente vai começar com uma arquitetura de microsserviços, por exemplo;
Não se apegar a Patterns e recursos enquanto eles não forem necessários:... é importante identificar em conjunto com o time que recursos atenderão melhor o domínio, e não mostrar um apego exagerado a certos recursos / frameworks antes de entender se eles realmente representam um ganho para o projeto;
Aproveitar as oportunidades de melhoria: Pode ser que, após diversas interações, o time tenha amadurecido o suficiente para ver que a implementação está limitando o crescimento do projeto. Bom, talvez tenha chegado a hora de refatorar parte, ou até mesmo todo o código."
Eduardo Pires também comenta que não é necessário implementar todas as camadas para ter o DDD: "O DDD não prega a necessidade de uma arquitetura de 4 camadas (Presentation, Application, Domain e Infra). Pelo contrário, o arquiteto tem a liberdade de definir o melhor estilo arquitetural para atender a necessidade da aplicação, podendo utilizar modelos simples de 3 camadas como o Table Module Pattern."[3]

Implementações

Uma implementação muito conhecida para .net é o ASP.NET Boilerplate, que tem a implementação das 4 camadas para o DDD:
"Presentation Layer: Provides an interface to the user. Uses the Application Layer to achieve user interactions.
Application Layer: Mediates between the Presentation and Domain Layers. Orchestrates business objects to perform specific application tasks.
Domain Layer: Includes business objects and their rules. This is the heart of the application.
Infrastructure Layer: Provides generic technical capabilities that support higher layers mostly using 3rd-party libraries." [4]
ASP.NET Boilerplate Application Architecture Model

Fontes

[0] [Livro "Domain-Driven Design: Tackling Complexity in the Heart of Software (Inglês)" do Eric Evans (Autor)] (http://amzn.to/2G1o9mZ)
[1] https://www.lambda3.com.br/2017/10/desmistificando-o-ddd/
[2] https://www.lambda3.com.br/2017/11/ddd-aplicado-case-fluxo-de-producao-de-equipamentos-por-demanda/
[3] http://www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/
[4] https://aspnetboilerplate.com/Pages/Documents/NLayer-Architecture
https://www.pluralsight.com/courses/domain-driven-design-fundamentals
https://www.lambda3.com.br/2016/10/podcast-14-domain-driven-design/

terça-feira, 21 de novembro de 2017

Configurando o TFVC no VS Code

dSe você trabalha com o Team Foundation Version Control (TFVC) com o Visual Studio, deve conseguir configura-lo com poucos passos. Mas se trabalha com o VS Code a coisa é menos trivial, já que é feita pela extensão "Visual Studio Team Services extension for Visual Studio Code". O cenário fica ainda mais complicado se você trabalha com Linux.

Para começar, é importante conhecer alguns conceitos como Workspace, Workfold. Depois é importante conhecer a linha de comando, já que a extensão utiliza só o executável TF e muitos dos diagnóticos das situações de problema são feitos utilizando linhas de comando.

Vamos primeiro no passo a passo do que precisa ser feito e no fim do post coloco informações adicionais que pode lhe ajudar a procurar soluções para problemas do seu ambiente.

Configurando a Extensão

Abra o VS Code, vá no ícone Source Control (esquerda), clique nos "..." e depois no Install Additional SCM Providers


Selecione o Visual Studio Team Services







Ao término clique na opção Reload.
Depois vá na opção File, Preferences, Settings:





Busque por tfvc e edite as propriedades
"tfvc.location": (local do executável TF , no meu caso era "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\TeamExplorer\\Common7\\IDE\\CommonExtensions\\Microsoft\\TeamFoundation\\Team Explorer\\TF.exe)
"tfvc.restrictWorkspace": true

Dica 1


Assim que configurei o usando o TF.exe do Visual Studio 2105 tive o erro : "It appears you have configured a non-English version of the TF executable. Please ensure an English version is properly configured.", que corrigi instalando o Visual Studio Team Explorer 2017 e renomeando a pasta de localização de "pt-BR" que nessa resposta do stackoverflow expliquei com mais detalhes.

Instalando o Visual Studio Team Explorer 2017

O Visual Studio Team Explorer 2017 é "Uma solução gratuita para não desenvolvedores interagirem com o Team Foundation Server e Visual Studio Team Services." e pode ser baixado neste link.
Ao instalar selecione os pacotes de língua inglês e português(que virá marcado por padrão se seu sistema operacional estiver nessa língua).


Faça a conexão com o TFS na collection desejada. Isso pode ser feito com o comando:
tf workspaces -collection:URL_COLLECTION_TFS

Crie um Workspace local:
tf workspace -new -collection:URL_COLLECTION_TFS -location:local myWorkspaceName

Mapeie um diretório remoto a um diretório local:
tf workfold -map '$/PATH_SERVER' 'C:\PATH_LOCAL' -collection:URL_TFS /workspace:myWorkspaceName

Feito isso deveria ser possível abrir o vscode no c:\path_local, abrir a paleta de comandos (atalho pelo f1) e executar o comando "Team:Sign". Mas tive o erro resolvido com o workaround dessa issue.

Conhecimento adicional para solução de problema

Se algo não funcionar habilite do log da extensão. Isso poderá ser feito dentro do VS Code, no menu File, Preferences, Settings. Adicione a chave "team.logging.level": "debug".
Um arquivo chamado "team-extension.log" será criado localmente na raiz do workspace.
O artigo "Use Team Foundation version control commands" explica
1) Comandos de configuração do ambiente na parte "Set up your dev machine and manage workspaces"
2) Comandos de desenvolvimento na parte "Develop your app", "Suspend your work", "Contribute your work"
3) Comandos para gerenciar arquivos e resolver conflitos "Manage files and solve problems"