Apresentando o Equinox Project

O Equinox Project é um projeto open-source desenvolvido em ASP.NET Core que implementa uma série de tecnologias e abordagens muito utilizadas em grandes projetos.

O Equinox Project é a mais recente contribuição que eu entrego a comunidade técnica e espero que seja de grande ajuda para servir de referência nos futuros projetos escritos em ASP.NET Core.

The Equinox Project

O Equinox Project (versão 1.0) é o resultado de quase duas semanas de estudos e desenvolvimento que dediquei ao criar uma aplicação funcional implementando diversas tecnologias e abordagens na nova plataforma ASP.NET Core.

Por ser totalmente desenvolvido com .NET Core esta aplicação pode rodar em ambientes Windows, Linux e OSX (Mac).

Tecnologias/Recursos Implementados

  • ASP.NET Core 1.1 (com .NET Core)
    • ASP.NET MVC Core
    • ASP.NET Identity Core
      • Isolado do MVC e Autenticando via
        Facebook ou Cadastro
  • Entity Framework Core
  • AutoMapper
  • .NET Core Native DI (Isolado do MVC)
  • Unit of Work
  • Repository e Generic Repository
  • FluentValidator

Arquitetura

  • Arquitetura completa com separação de responsabilidades, SOLID e Clean Code
  • DDD – Domain Driven Design (Camadas e Domain Model Pattern)
  • Domain Events
  • Domain Notifications
  • CQRS (Com consistência imediata)
  • Event Sourcing

Versão 1.0

 O Equinox Project na versão 1.0 implementa um cadastro de clientes (CRUD) com regras de negócio e validações de dados.

  • Toda escrita de dados ocorre através de Commands e CommandHandlers que são processados por um Bus em memória (podendo ser adaptado para um Message Queue por exemplo).
  • Após a execução de um Command é disparado um Evento que realiza alguma ação informativa e também é persistido na base (Event Sourcing).
  • A leitura de dados ocorre de forma mais simples dispensando algumas camadas de negócio.
  • Todas as ações são autorizadas pelo mecanismo do ASP.NET Identity que baseia-se em Claims para permitir a leitura e escrita dos dados.
  • As validações de consistência dos dados são realizadas nos Commands e utilizam o FluentValidator como mecanismo.
  • Todos os erros no processamento ou na validação dos dados são disparados através de Domain Events/Notifications e são informados ao usuário de forma personalizada.
  • É possível visualizar a história da entidade através da aplicação que informa desde a criação até a exclusão as mudanças dos dados que ocorreram e o usuário que as executou.

Estes são alguns dos recursos implementados, existem diversos outros em toda extensão da aplicação. Cada um destes recursos eu irei tratar em artigos individuais em uma nova série sobre ASP.NET Core que irei iniciar muito em breve.

Aviso

  • Este projeto não pretende ser uma solução definitiva para todos os cenários.
  • Algumas versões utilizadas (inclusive do ASP.NET Core 1.1) estão em Beta ou Pre-Release.
  • Cuidado ao utilizar este projeto na sua produção. Analise bem os riscos de ser um Early Adopter.
  • Talvez você não irá precisar de muitos dos recursos implementados, procure evitar o OverEngineering

Sobre o futuro

A versão 2.0 do Equinox Project será uma aplicação bem mais extensa com os recursos a seguir:

  • Aplicação completa de aluguel (Booking) utilizando Domain Model Pattern, CQRS e Event Sourcing.
  • ASP.NET Identity trabalhando através de serviços WebAPI com Bearer Token
  • Novo front-end
  • Bancos separados para leitura e gravação de dados
  • Testes de Unidade

Acompanhe os detalhes que serão atualizados no RoadMap do projeto.

Sugestões?

Tem uma boa ideia sobre implementação ou gostaria de ver algo implementado?
Sugestões e críticas serão muito bem vindas!

Por que Equinox?

O Equinócio (Equinox) é um evento astronômico em que o plano do equador da Terra passa pelo centro do Sol. Este evento ocorre duas vezes por ano em torno de 20 de Março e 23 de Setembro. Wikipedia

Equinox é também uma série de publicações (subtítulo: “The Review of Scientific Illuminism”) em forma de livro que serve como o órgão oficial da A∴A∴, uma ordem iniciática fundada por Aleister Crowley Wikipedia

Estamos Online

O projeto está publicado *orgulhosamente* no Microsoft Azure, experimente!

Código Fonte

The Equinox Project – GitHub


Caso esteja interessado em conhecer mais sobre ASP.NET, DDD, Padrões de Arquitetura como CQRS, Event Sourcing e boas práticas de desenvolvimento não deixe de conferir as ementas dos meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Turbinando sua aplicação ASP.NET no IIS

Toda aplicação ASP.NET requer um processo de compilação em memória no servidor e isto leva um tempo perceptível por nossos usuários. Aprenda como evitar esse comportamento.

Turbinando sua aplicação ASP.NET no IIS

Na minha vida de consultor eu sempre ouço a mesma pergunta dos meus clientes:
Meu site fica lento na primeira chamada toda vez que faço um deploy ou quando o pool do IIS recicla naturalmente.

Antes de tudo é importante deixar claro que não tem como fugir do processo de reciclagem do pool do IIS, ele pode ocorrer naturalmente por N fatores ou agendado conforme sua configuração.

A demora natural na primeira chamada de uma aplicação ASP.NET é o processo do IIS compilando o assembly da sua aplicação e disponibilizando ele num cache, esse cache é usado nas próximas chamadas e assim sua aplicação volta a responder normalmente sem nenhuma demora aparente. Toda vez que o pool do IIS recicla a memória esse cache é perdido.

Nós não queremos que nossos usuários sejam obrigados a esperar este tempo de compilação que pode chegar em cerca de 30 segundos dependendo do tamanho da aplicação, é por isso que o IIS possui uma feature pouco utilizada chamada de
IIS Auto-Start ou Application Initialization

Para habilitar esse comportamento no seu IIS é necessário instalar o módulo de Application Initialization no seu servidor e seguir alguns passos na configuração do IIS.

*A mesma configuração pode ser feita através da edição dos arquivos de configuração no servidor. Eu prefiro fazer no IIS diretamente, você encontrará esta outra abordagem no link de referência no final do post.

O resultado é muito satisfatório, ao invés da aplicação demorar mais de 10 segundos para responder ela passa a demorar 1 ou 2 segundos.

Para abordar todos os passos necessários em detalhes eu gravei um vídeo de 16 minutos mostrando todo o processo de configuração.

* Assine meu canal no Youtube 🙂

Referências


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

DDD não é arquitetura em camadas

O DDD tornou-se um tema altamente debatido e naturalmente uma série de equívocos surgiram através dos diferentes entendimentos sobre o assunto.

Vou citar algumas perguntas / afirmações que venho observando faz alguns anos e são a minha principal motivação para escrever este post.

  • Como faço para persistir uma entidade com Entity Framework no DDD?
  • Como faço para popular um DropDownList seguindo o padrão DDD?
  • Iniciei um novo projeto em MVC + DDD na minha empresa e tenho uma dúvida.
  • Estou criando um back-end em WebAPI + DDD
  • Onde coloco uma camada de cache num projeto DDD?
  • Existe algum framework de DDD em .NET?

DDD não é arquitetura em camadas.

O DDD é uma abordagem de modelagem de software que segue um conjunto de práticas com objetivo de facilitar a implementação de complexas regras / processos de negócios que tratamos como domínio.

Domain Driven Design como o nome já diz é sobre design. Design guiado pelo domínio, ou seja, uma modelagem de software focada em resolver problemas na complexidade do negócio.

“Toda arquitetura é design, mas nem todo design é arquitetura” – Grady Booch

O DDD não é uma receita pronta sobre como desenvolver uma arquitetura baseada em Presentation, Services, Application, Domain e Infra.

DDD não é tecnologia.

O DDD não depende da tecnologia que você irá utilizar para fornecer sua aplicação seja ela ASP.NET MVC, WebAPI, SPA, Windows Forms ou etc.

O DDD não irá influenciar em diversas decisões:

  • Como preencher um controle na camada de apresentação
  • Como expor uma API REST
  • Qual tecnologia usar para persistir os dados
  • Como realizar o deploy da aplicação
  • Como modelar seu banco de dados
  • Como trabalhar com camadas de Infra (ex. Cache, Log, IoC)
  • Qualquer outra decisão de tecnologia.

Evite as gafes

Evite utilizar o termo DDD acompanhado de questões que não envolvem diretamente os conceitos do DDD, pois pode dar a entender que você não compreendeu sobre do que se trata o assunto.

Então do que se trata o DDD?

O DDD resgatou e catalogou uma série de boas práticas que foram ignoradas durante anos na maioria dos projetos e na minha opinião esta é a maior conquista do autor na concepção da sua ideia.

Eric Evans em seu livro aborda desde o primeiro capítulo a preocupação no entendimento do negócio, pois entender e destilar o negócio é o único meio de implementar o DDD em um projeto.

Não existe um modelo passo-a-passo de como implementar o DDD, mas podemos tentar criar um resumo básico:

Passo #1 – Entender o Negócio

Sem entender o negócio não tem como implementar o DDD. Em um projeto existem basicamente dois tipos de papéis, o Time de Desenvolvimento e os Domain Experts.
Os Domain Experts entendem do negócio e vão guiar o time de desenvolvimento no projeto tirando dúvidas, definindo regras e processos e nomeando os termos a serem utilizados.

Passo #2 – Extrair a Linguagem Ubíqua

A Linguagem Ubíqua é uma linguagem compartilhada e desenvolvida pela equipe de Domain Experts e de Desenvolvimento. A Linguagem Ubíqua é a linguagem do negócio dentro da empresa e todos devem fazer uso dela para expressar corretamente todos processos / intenções de negócio.

Existem diversas técnicas para extrair e catalogar a Linguagem Ubíqua, cabe ao time definir a melhor maneira de colaborar.

Passo #3 – Modelagem Estratégica

Extrair a Linguagem Ubíqua vai colaborar na visão e entendimento do negócio e como segregar seu domínio em partes menores e responsáveis.

DDD Context Map

Para documentar estas segregações responsáveis utilizamos o Mapa de Contextos (Context Map) que pode ser representado através de imagens e uma simples documentação do tipo de relacionamento entre os contextos.

Além de delimitar os contextos a modelagem estratégica engloba outros conceitos como  Sub-Domain, Shared Kernel, Customer/Supplier, Conformist, Anti-Corruption Layer, Separate Ways, Open Host Service e Published Language.

Cada contexto delimitado possui sua própria Linguagem Ubíqua, para entender melhor estes conceitos eu escrevi um artigo falando sobre os Bounded Contexts.

Nota: Eu acredito que não existe uma forma de implementar o DDD sem aplicar os conceitos da modelagem estratégica. Inclusive o próprio Eric Evans comentou que se ele fosse escrever seu livro nos dias de hoje ele teria começado pelo conceito de Bounded Contexts.

Passo #4 – Definir a Arquitetura

Tendo uma clara visão do Context Map é possível trabalhar na definição da arquitetura.

Cada contexto pode possuir uma arquitetura independente dos demais, não é necessário impor o mesmo estilo arquitetural para todos os contextos.

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.

Existem diversos estilos arquiteturais como a clássica Arquitetura CebolaArquitetura Hexagonal proposta pelo Vernon em seu livro Implementing Domain Driven Design ou até mesmo os populares Microservices. Alguns destes estilos inclusive podem fazer uso de patterns como CQRS, Event Sourcing, etc.

Um arquiteto deve conhecer os estilos e patterns arquiteturais e saber reconhecer onde e quando devem ser utilizados.

Passo #5 – Modelagem Tática

Quando o assunto é DDD a modelagem tática fica por conta do Domain Model Pattern que é uma abordagem de como escrever as classes que vão mapear os modelos do mundo real e implementar os comportamentos do negócio.

O Domain Model Pattern deve ser isolado dos detalhes da sua arquitetura como persistência e etc.

O Eric Evans não criou os patterns utilizados no Domain Model, apenas fez o uso correto deles criando então esta abordagem de modelagem tática que incluem os seguintes componentes:

  • Aggregate Object
    Uma entidade que é a raiz agregadora de um processo do domínio que envolve mais de uma entidade.
  • Domain Model
    Uma entidade do domínio, possui estados e comportamentos, lógica de negócio, getters e setters AdHoc, etc.
  • Value Object
    Um objeto que agrega valor às entidades, não possui identidade e é imutável.
  • Factory
    Classe responsável por construir adequadamente um objeto / entidade.
  • Domain Service
    Serviço do domínio que atende partes do negócio que não se encaixam em entidades específicas, trabalha com diversas entidades, realiza persistência através de repositórios e etc.
  • Application Service
    Serviço de aplicação que orquestra ações disparadas pela camada de apresentação e fornece DTOs para comunicação entre as demais camadas e para o consumo da camada de apresentação.
  • Repository
    Uma classe que realiza a persistência das entidades se comunicando diretamente com o meio de acesso aos dados, é utilizado apenas um repositório por agregação.
  • External Service
    Serviço externo que realiza a consulta/persistência de informações por meios diversos.

Se você trabalhou em todos os passos citados, parabéns! Você provavelmente está implementando o DDD. Fique a vontade para utilizar técnicas como TDD e BDD e sinta-se livre para escolher a plataforma da camada de apresentação ou como distribuir suas API’s etc. Afinal este não é o foco e nem uma exigência do DDD.

Quando devo utilizar o DDD?

Apesar de muitas pessoas afirmarem utilizar DDD apenas por possuir uma arquitetura em camadas isto não significa que realmente estejam usando o DDD, existem algumas interpretações como DDD-Lite que seria uma aplicação utilizando alguns conceitos encontrados no DDD porém ignorando muitos outros.

Uma analogia a este cenário seria um time de desenvolvimento dizer que utiliza Scrum como uma metodologia de desenvolvimento ágil quando somente faz uso de um quadro Kanban e ignora as práticas de sprints, cerimônias etc. Nós chamamos isto de ScrumBut.

Espero que tenha ficado claro até este ponto o que é realmente o DDD e os passos principais para implementá-lo. Para saber se você deve ou não implementar o DDD no seu projeto, disponibilizo abaixo um DDD Score Card extraído do livro Implementing Domain Driven Design.

A ideia é bem simples, a primeira coluna descreve seu projeto, em seguida o número de pontos que devem ser acumulados, a última coluna descreve algumas concepções.
Se no final a somatória dos pontos for igual ou maior que 7 considere seriamente em implementar o DDD em seu projeto.

Se seu Projeto… Pontos Pensamentos de Suporte
Se sua aplicação for completamente centrada em dados e se qualificar verdadeiramente para uma solução CRUD pura, em que cada operação é basicamente uma consulta simples de banco de dados para criar, ler, atualizar ou excluir, você não precisa do DDD. Sua equipe só precisa colocar um rosto
bonito em um editor de tabelas de banco de dados. Em outras palavras, se você puder confiar no fato de que os usuários irão inserir os dados diretamente em uma tabela, atualizá-los e, às vezes, excluí-los, você nem mesmo precisará de uma interface do usuário. Isso não é realista, mas é conceitualmente relevante. Se pudesse usar uma ferramenta simples de desenvolvimento de banco de dados para criar uma solução, você não desperdiçaria o tempo e dinheiro de sua empresa no DDD.
0 Isso parece óbvio, mas normalmente não é fácil determinar
simples versus complexo. Não é como se todas as aplicações que não são CRUD puras merecem o tempo e o esforço
do uso do DDD. Assim, talvez possamos sugerir outros indicadores para nos ajudar a traçar uma linha entre o que é complexo e o que não é …
Se seu sistema exigir apenas 30 ou menos operações de
negócio, ele provavelmente é bem simples. Isso significaria
que a aplicação não teria um total de mais de 30 histórias de usuário ou fluxos de caso de uso, com cada um desses fluxos tendo apenas uma lógica mínima de negócio. Se você puder desenvolver rápida e facilmente esse tipo de aplicação e não se importar com a falta de poder e controle em relação à complexidade e alteração, o sistema provavelmente não precisará usar o DDD.
1 Para ser claro, estou falando de 25 a 30 únicos métodos de negócio, não de 25 a 30 interfaces de serviço completas, cada uma com vários métodos. O último pode ser complexo.
Assim, digamos que, em algum lugar no intervalo entre 30 e 40 histórias de usuário ou fluxos de caso de uso, a complexidade poderia ser pior. Seu sistema pode estar entrando no território do DDD. 2 O risco é do comprador: Bem frequentemente a complexidade não é reconhecida rapidamente. Nós, desenvolvedores de software, somos realmente muito bons para subestimar a complexidade e o nível de esforços. Só porque talvez queiramos codificar uma aplicação em N camadas com diversos Patterns não significa que devemos. No longo prazo, essas aplicações poderiam prejudicar mais do que ajudar.
Mesmo que a aplicação não seja complexa agora, a complexidade dela aumentará? Você só pode saber isso ao certo depois que os usuários reais começam a trabalhar com ela, mas há um passo na coluna “Pensamentos de suporte” que pode ajudar a revelar a situação real.
Tenha cuidado aqui. Se houver absolutamente qualquer indício de que a aplicação tem complexidade mesmo moderada — este é um bom momento para ser paranoico —, isso pode ser uma indicação suficiente de que ela na verdade será mais do que moderadamente complexa. Incline-se em direção ao DDD.
3 Aqui vale a pena analisar os cenários de uso mais complexos com especialistas em domínio e ver aonde eles levam.Os especialistas em domínio:
#1 Já estão solicitando recursos mais complexos? Se sim, isso provavelmente é uma indicação de que a aplicação já é ou em breve se tornará excessivamente complexa para usar uma abordagem CRUD.#2 Estão entediados com os recursos ao ponto em que dificilmente vale a pena discuti-los? Provavelmente não é complexa.
Os recursos da aplicação serão alterados com frequência ao longo de alguns anos, e você não pode antecipar que as alterações serão simples. 4 O DDD pode ajudá-lo a gerenciar a complexidade da refatoração de seu modelo ao longo do tempo.
Você não entende o Domínio porque ele é novo. Na medida em que você e sua equipe sabem, ninguém fez isso antes. Isso provavelmente significa que ele é complexo ou, pelo menos, merece a devida diligência com análise analítica para determinar o nível de complexidade. 5 Você precisará trabalhar com Domain Experts e testar os modelos para fazer a coisa certa. Você certamente também pontuou em um ou mais dos critérios anteriores, portanto, use o DDD.

Ao finalizar este exercício você terá mais clareza para determinar se o DDD é viável ou não para o seu projeto. Lembre-se de tomar as decisões com foco na simplicidade, entrega e manutenção. Muitas vezes sofremos da vontade incontrolável de implementar todos os conceitos de nossos estudos, porém estamos colocando em risco o dinheiro da empresa e nossa própria carreira.

Erros comuns

Agora que está muito claro o que é o DDD e se ele é viável para seu projeto, gostaria de alertar sobre os erros mais comuns cometidos pela maioria dos desenvolvedores.

#1 – Permitir que o meio de persistência influencie diretamente nas entidades.

Quando utilizamos ORM’s para mapear o banco e nossas entidades muitas vezes somos obrigados a “infectar” nossos modelos com necessidades do ORM utilizado. Evite ao máximo tomar decisões que impactem em suas entidades e que no final servem apenas para atender as necessidades do meio de persistência.

 #2 – Não se envolver com os Domain Experts

Ignorar o conhecimento de negócio dos Domain Experts é uma falha grave, busque envolvê-los diretamente no projeto e nas decisões. Documentar alguns processos com BDD é uma ótima maneira de aproximar todos os envolvidos em uma conversa fluente e clara.

Se na sua empresa não existe o “Domain Expert” não tem problema, com certeza existe alguém que conheça bem do negócio, traga esta pessoa para participar ativamente no projeto.

#3 – Ignorar a Linguagem Ubíqua

A Linguagem Ubíqua é a linguagem do negócio, deixar de extraí-la e mapeá-la poderá acarretar em sérios problemas de comunicação que irão refletir diretamente no entendimento dos requisitos e no código fonte. Será um grande problema no futuro.

#4 – Não identificar os limites dos contextos

Pular a parte da modelagem estratégica é um dos maiores erros que se pode cometer ao implementar o DDD. Isto tornará sua aplicação extremamente complexa e monolítica, é o princípio de uma grande bola de lama (Big Ball of Mud).

#5 – Escrever entidades anêmicas

O uso de entidades anêmicas é sinal de uma grande falta de entendimento no comportamento de uma entidade, quebra o próprio conceito da OOP que diz que um objeto deve possuir estados e comportamentos. Uma entidade no mínimo deve saber se auto-validar para garantir sua consistência, logo não existem motivos para escrever entidades anêmicas.

#6 – Assumir que toda lógica é lógica de domínio 

Nem toda validação é responsabilidade do domínio. Por exemplo o tratamento de acesso e permissões de usuário, isto é responsabilidade da aplicação. Deixar todas as validações por conta do domínio também é uma falha, num cenário Web a camada de apresentação também pode realizar as validações necessárias para filtrar as requisições no servidor.

#7 – Focar demais na infra-estrutura

Implementar um projeto com DDD significa trabalhar com foco no negócio, iniciar o projeto pela modelagem do banco de dados e preocupando-se com os meios de persistência são erros que podem pode gerar impactos negativos nos seus modelos de domínio. A camada de infra-estrutura serve para suportar responsabilidades que não são do domínio, foque nas implementações de infra-estrutura conforme a necessidade surgir.

Resumindo

Implementar o DDD em seu projeto pode ser uma ótima decisão que proporcionará mais facilidades para atender aos complexos processos de negócio. Tornará a equipe mais colaborativa e focada no que é realmente mais importante.

Não se aventure no escuro! Antes de iniciar um projeto em DDD é necessário ter um bom conhecimento teórico e prático em todos os conceitos abordados neste artigo. Eu recomendo fortemente a leitura de livros, cursos e demais conteúdos que irão lhe preparar para que este desafio não se torne um grande desastre.

E por fim evite de utilizar o DDD como referência para arquitetura em camadas, agora você já sabe que não é disto que se trata o DDD.


Caso esteja interessado em conhecer mais sobre o DDD, Padrões de Arquitetura como CQRS, Event Sourcing e boas práticas de desenvolvimento não deixe de conferir a ementa do meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

CQRS – O que é? Onde aplicar?

CQRS é uma daquelas siglas que está cada vez mais presente em nossas leituras, muitas vezes encontramos o CQRS sendo citado em conteúdos sobre DDD ou padrões de arquitetura escaláveis.

CQRS é um conceito muito importante e você precisa conhecer. Eu costumo dizer que todo arquiteto possui uma “caixa de ferramentas” e o CQRS é o tipo de ferramenta que precisa estar presente na sua caixa.

O que é CQRS?

CQRS significa Command Query Responsibility Segregation. Como o nome já diz, é sobre separar a responsabilidade de escrita e leitura de seus dados.

CQRS é um pattern, um padrão arquitetural assim como Event Sourcing, Transaction Script e etc. O CQRS não é um estilo arquitetural como desenvolvimento em camadas, modelo client-server, REST e etc.

Onde posso aplicar o CQRS?

Antes de entrar neste ponto vamos entender os cenários clássicos do dia a dia e depois veremos como o CQRS poderia ser aplicado como solução.

Hoje em dia não desenvolvemos mais aplicações para 10 usuários simultâneos, a maioria das novas aplicações nascem com premissas de escalabilidade, performance e disponibilidade. Como uma aplicação pode funcionar bem com 10 ou 10.000 usuários simultaneamente? É uma tarefa complexa criar um modelo conceitual que atenda essas necessidades.

Imagine um sistema de SAC onde diversos atendentes num call-center consultam e modificam as informações de um cadastro de clientes enquanto outra área operacional da empresa também trabalha com os mesmos dados simultaneamente. Os dados do cliente são modificados constantemente e nenhuma das áreas tem tempo e paciência para esperar os possíveis “locks” da aplicação, o cliente quer ser atendido com agilidade.

No mesmo cenário a aplicação pode possuir picos diários ou sazonais de acessos. Como impedir o tal “gargalo” e como manter a disponibilidade da aplicação em qualquer situação?

– Ah! Vamos escalar nossa aplicação em N servidores. Podemos migrar para a nuvem (cloud-computing ex. Azure) e criar um script de elasticidade (Autoscaling) para escalar conforme a demanda.

O conceito de escalabilidade da aplicação vai resolver alguns problemas de disponibilidade como por exemplo suportar muitos usuários simultaneamente sem comprometer a performance da aplicação.

Mas será que só escalar os servidores de aplicação resolve todos os nossos problemas?

Problema # 1

Deadlocks, timeouts e lentidão, seu banco pode estar em chamas.

CQRS Banco em Chamas

Escalar a aplicação não é uma garantia de que a aplicação vai estar sempre disponível. Não podemos esquecer que neste suposto cenário todo processo depende também da disponibilidade do banco de dados.

Escalar o banco de dados pode ser muito mais complexo (e caro) do que escalar servidores de aplicação. E geralmente é devido o consumo do banco de dados que as aplicações apresentam problemas de performance.

Problema # 2

Para se obter um dado muitas vezes é necessário passar por um conjunto complexo de regras de negócio que irá filtrar a informação antes dela ser exibida, além disso existem os ORM’s que mapeiam o banco de dados em objetos de domínio realizando consultas com joins em diferentes tabelas para retornar todo conjunto de dados necessários.
Tudo isto custa um tempo precioso até que o usuário receba a informação esperada.

Problema # 3

Um conjunto limitado de dados é consultado e alterado constantemente por uma grande quantidade de usuários simultaneamente conectados. Um dado exibido na tela já pode ter sido alterado por outro. Numa visão realista é possível afirmar que toda informação exibida já pode estar obsoleta.

Ponto de partida

Ter N servidores consumindo um único banco de dados que serve de leitura e gravação pode ocasionar muitos locks nos dados e com isso ocasionar diversos problemas de performance, assim como todo o processo da regra de negócio que vai obter os dados de exibição cobra um tempo a mais no processamento. No final ainda temos que considerar que o dado exibido já pode estar desatualizado.

É este o ponto de partida do CQRS. Já que uma informação exibida não é necessariamente a informação atual então a obtenção deste dado para a exibição não necessita ter sua performance afetada devido a gravação, possíveis locks ou disponibilidade do banco.

O CQRS prega a divisão de responsabilidade de gravação e escrita de forma conceitual e física. Isto significa que além de ter meios separados para gravar e obter um dado os bancos de dados também são diferentes. As consultas são feitas de forma síncrona em uma base desnormalizada separada e as gravações de forma assíncrona em um banco normalizado.

CQRS Fluxo Simples

Este é um fluxo simplificado do CQRS que não leva em consideração as camadas de aplicação, domínio e infra, comandos / eventos e enfileiramento de mensagens.

O CQRS não é um padrão arquitetural de alto-nível, podemos entender como uma forma de componentizar parte de sua aplicação. Podemos entender então que a utilização do CQRS não precisa estar presente em todos os processos de sua aplicação. Numa modelagem baseada em DDD um Bounded Context pode implementar o CQRS enquanto os demais não.

Não existe uma única maneira de implementar o CQRS na sua aplicação, pode ser feito de uma forma simples ou muito complexa, depende da necessidade. Independente de como for implementado o CQRS sempre acarreta numa complexidade extra e por isso é necessário avaliar os cenários em que realmente são necessários trabalhar com este padrão.

Entendendo melhor o CQRS

A ideia básica é segregar as responsabilidades da aplicação em:

  • Command – Operações que modificam o estado dos dados na aplicação.
  • Query – Operações que recuperam informações dos dados na aplicação.

Numa arquitetura de N camadas poderíamos pensar em separar as responsabilidades em CommandStack e QueryStack.

QueryStack

A QueryStack é muito mais simples que a CommandStack, afinal a responsabilidade dela é recuperar dados praticamente prontos para exibição. Podemos entender que a QueryStack é uma camada síncrona que recupera os dados de um banco de leitura desnormalizado.

Este banco desnormalizado pode ser um NoSQL como MongoDB, Redis, RavenDB etc.
O conceito de desnormalizado pode ser aplicado com “one table per view” ou seja uma consulta “flat” que retorna todos os dados necessários para ser exibido em uma view (tela) específica.

O uso de consultas “flats” em um banco desnormalizado evita a necessidade de joins, tornando as consultas muito mais rápidas. É preciso aceitar que haverá a duplicidade de dados para poder atender este modelo.

CommandStack

O CommandStack por sua vez é potencialmente assíncrono. É nesta separação que estão as entidades, regras de negócio, processos e etc. Numa abordagem DDD podemos entender que o Domínio pertence a esta parte da aplicação.

O CommandStack segue uma abordagem behavior-centric onde toda intenção de negócio é inicialmente disparada pela UI como um caso de uso. Utilizamos o conceito de Commands para representar uma intenção de negócio. Os Commands são declarados de forma imperativa (ex. FinalizarCompraCommand) e são disparados assincronamente no formato de eventos, são interpretados pelos CommandHandlers e retornam um evento de sucesso ou falha.

Toda vez que um Command é disparado e altera o estado de uma entidade no banco de gravação um processo tem que ser disparado para os agentes que irão atualizar os dados necessários no banco de leitura.

Sincronização

Existem algumas estratégias para manter as bases de leitura e gravação sincronizadas é necessário escolher a que melhor atende ao seu cenário:

  • Atualização automática – Toda alteração de estado de um dado no banco de gravação dispara um processo síncrono para atualização no banco de leitura.
  • Atualização eventual – Toda alteração de estado de um dado no banco de gravação dispara um processo assíncrono para atualização no banco de leitura oferecendo uma consistência eventual dos dados.
  • Atualização controlada – Um processo periódico e agendado é disparado para sincronizar as bases.
  • Atualização sob demanda – Cada consulta verifica a consistência da base de leitura em comparação com a de gravação e força uma atualização caso esteja desatualizada.

A atualização eventual é uma das estratégias mais utilizadas, pois parte do princípio que todo dado exibido já pode estar desatualizado, portanto não é necessário impor um processo síncrono de atualização.

Enfileiramento

Muitas implementações de CQRS podem exigir um “Bus” para processamento de Commands e Events. Nesse caso teremos uma implementação conforme a seguinte ilustração.

CQRS BUS

Existem diversas opções de Bus para .NET

Vantagens de implementar o CQRS

A implementação do CQRS quebra o conceito monolítico clássico de uma implementação de arquitetura em N camadas onde todo o processo de escrita e leitura passa pelas mesma camadas e concorre entre si no processamento de regras de negócio e uso de banco de dados.

Este tipo de abordagem aumenta a disponibilidade e escalabilidade da aplicação e a melhoria na performance surge principalmente pelos aspectos:

  • Todos comandos são assíncronos e processados em fila, assim diminui-se o tempo de espera.
  • Os processos que envolvem regras de negócio existem apenas no sentido da inclusão ou alteração do estado das informações.
  • As consultas na QueryStack são feitas de forma separada e independente e não dependem do processamento da CommandStack.
  • É possível escalar separadamente os processos da CommandStack e da QueryStack.

Uma outra vantagem de utilizar o CQRS é que toda representação do seu domínio será mais expressiva e reforçará a utilização da linguagem ubíqua nas intenções de negócio.

Toda a implementação do CQRS pattern pode ser feito manualmente, sendo necessário escrever diversos tipos de classes para cada aspecto, porém é possível encontrar alguns frameworks de CQRS que vão facilitar um pouco a implementação e reduzir o tempo de codificação.

Apesar da minha preferência ser sempre codificar tudo por conta própria eu encontrei alguns frameworks bem interessantes que servem inclusive para estudo e melhoria do entendimento no assunto.

Mitos sobre o CQRS

#1 Mito – CQRS e Event Sourcing devem ser implementados juntos.

O Event Sourcing é um outro pattern assim como o CQRS. É uma abordagem que nos permite guardar todos os estados assumidos por uma uma entidade desde sua criação. O Event Sourcing tem uma forte ligação com o CQRS e é facilmente implementado uma vez que temos também o CQRS, porém é possível implementar Event Sourcing independente do CQRS e vice-versa.

Escreverei sobre Event Sourcing em breve num outro artigo.

#2 Mito – CQRS requer consistência eventual

Negativo. Como abordado anteriormente o CQRS pode trabalhar com uma consistência imediata e síncrona.

#3 Mito – CQRS depende de Fila/Bus/Queues

CQRS é dividir as responsabilidades de Queries e Commands, a necessidade de enfileiramento vai surgir dependendo de sua implementação, principalmente se for utilizar a estratégia de consistência eventual.

#4 Mito – CQRS é fácil

Não é fácil. O CQRS também não é uma ciência de foguetes. A implementação vai exigir uma complexidade extra em sua aplicação além de um claro entendimento do domínio e da linguagem ubíqua.

#5 Mito – CQRS é arquitetura

Não é! Conforme foi abordado o CQRS é um pattern arquitetural e pode ser implementado em uma parte específica da sua aplicação para um determinado conjunto de dados apenas.

Referências externas


Caso esteja interessado em conhecer mais sobre o CQRS, Event Sourcing, DDD e boas práticas de desenvolvimento não deixe de conferir a ementa do meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

O ASP.NET Brasil Conference 2016 foi um sucesso!

O ASP.NET Brasil Conference é o maior evento da América Latina sobre ASP.NET e em sua 3a edição recebeu mais de 600 participantes.

Eu como organizador do ASP.NET Brasil Conference estou extremamente satisfeito e muito feliz com o resultado do evento. Casa cheia, público animado, palestras de alto nível e infra-estrutura completa. Este foi um evento épico para ficar na história.

Como palestrante de eventos técnicos não é comum falar para um público tão grande, a maioria dos eventos não costumam reunir grandes quantidades de pessoas em uma única trilha e o sucesso de público foi um dos grandes motivos que tornou esta edição do evento tão especial.

Organizar um evento deste porte não é fácil, principalmente para uma equipe tão enxuta de três pessoas. Sim foram três pessoas, uma full-time e duas partial-time que rodaram todo o evento em um pouco menos de 6 meses de planejamento e execução.

Acompanhe a evolução do evento em 2014, 2015, 2016

 ASP.NET Brasil Conference 2016 – Sucesso de público

ASP.NET Brasil Conference 2016 - Keynote

ASP.NET Brasil Conference 2016 - Sucesso de Público

Um evento para a comunidade técnica

Diferente de outros eventos, o ASP.NET Brasil Conference não é um evento realizado para gerar lucros aos organizadores, todo o valor arrecadado é utilizado para custear o próprio evento e para fazer caixa para os próximos, assim conseguimos oferecer para nossos participantes diversos tipos de brindes e prêmios que também é um grande diferencial do evento em comparação aos outros do mesmo porte.

ASP.NET Brasil Conference 2016 - Brindes para os participantes

ASP.NET Brasil Conference 2016 - Prêmios Sorteados

Feedback excelente

Todos os participantes que preencheram as fichas de avaliação pontuaram em grande maioria entre bom e excelente todos os aspectos do evento. Tivemos bastantes feedbacks muito positivos nas redes sociais também.

Uma grande novidade para 2017

Anunciamos no keynote uma grande novidade, estamos planejando para 2017 um evento ainda maior, muitas trilhas e um público previsto de 1500 pessoas. Este novo evento será o DevXperience ou se preferir DevX.

ASP.NET Brasil Conference 2016 - Anuncio do DevXperience - DevX

Acompanhe as novidades do DevX no Facebook e Twitter e fique por dentro das trilhas, palestras e garanta sua inscrição o quanto antes.

Gostaria de agradecer a todos os participantes, palestrantes e staffs. Vocês fizeram do ASP.NET Brasil Conference 2016 um evento incrível!

No próximo post farei uma lista das palestras e disponibilizarei o material utilizado pelos palestrantes.
Até a próxima e nos vemos no DevXperience.

DDD – Bounded Context

Bounded Context é um conceito muito importante do DDD e pode ser a solução para a boa modelagem do seu domínio.

Bounded Context é um conceito tão importante quanto o entendimento da separação de responsabilidades das camadas do DDD. Você tem utilizado este conceito em sua aplicação? Cuidado! Você pode estar construindo uma grande bola de lama.

Bounded Context é um conceito razoavelmente fácil de se explicar, porém pode ser extremamente complexo de se implementar. Tudo depende da visão global do domínio da aplicação.

O que significa visão global do domínio?
Ter uma visão global significa enxergar toda a extensão de seu domínio e eu não estou me referindo as camadas, estou me referindo ao negócio.

Como ter uma visão global do negócio se a aplicação ainda não foi desenvolvida ou está em processo de desenvolvimento?
É necessário lutar contra a IVSF “Irresistível Vontade de Sair Fazendo” e focar antes em mapear seus contextos e definir os Bounded Contexts “contextos delimitados”. Para determinar seus Bounded Contexts você precisa ter um bom conhecimento do negócio da empresa ou ter ao seu lado um Domain Expert.

Domain Expert

É a pessoa que entende do negócio da empresa e vai apoiar os times de desenvolvimento na modelagem do domínio, definição das regras de negócio e etc. O domain expert também é responsável por definir a Ubiquitous Language “Linguagem Ubíqua”.

Context Map

Para a aplicação ter um bom design, uma fácil manutenção / extensibilidade e o domínio ser bem modelado é necessário focar em modelagem estratégica e para isso é importante preocupar-se com a integridade do modelo conforme o diagrama do Context Map apresenta.

Bounded Context - DDD - Context Map

Todos os conceitos do Context Map são importantes, é necessário compreender muito bem de cada um deles para termos condição de realizar uma boa modelagem.

Big Ball of Mud

A grande bola de lama. Você pode ter uma em suas mãos neste momento.
Este conceito aborda vários aspectos negativos de sua aplicação, desde código macarrônico que fere os princípios do SOLID e Clean Code até uma entidade com muitas responsabilidades em um único contexto. Analise a imagem a seguir:

Bounded Context - DDD - Big Ball of Mud - Grande Bola de Lama

A entidade Produto possui diversos comportamentos, cada um destes comportamentos está ligado a uma intenção da aplicação, todas as intenções são relativas ao produto em si, porém imagine a complexidade desta classe, quantas equipes de desenvolvimento estão compartilhando a mesma classe em comum.
A entidade Produto atende aspectos de Aquisição, Venda, Entrega, Estoque e etc.
Esse tipo de modelagem pode ser considerada um exemplo de Big Ball of Mud, pois qualquer manutenção nessa entidade pode ocasionar impactos sérios em diversos pontos da aplicação, é praticamente impossível de gerenciar as mudanças.

Como resolver ou evitar este tipo de cenário?
O DDD não é sobre dividir a aplicação em camadas responsáveis, o DDD é sobre modelar corretamente o domínio do seu negócio. Se sua aplicação possui uma única camada de domínio e esta camada concentra todas as entidades do seu negócio você pode estar cometendo um grande erro de modelagem de domínio. Para aplicações que possuem domínios muito complexos o ideal é aplicar o conceito de Bounded Context.

Bounded Context

Os contextos delimitados ou bounded contexts buscam delimitar o seu domínio complexo em contextos baseados nas intenções do negócio. Isto significa que você deve delimitar as intenções de suas entidades com base no contexto que ela pertence. Analise a imagem a seguir:

Bounded Context - DDD

O domínio foi subdividido em seis pedaços, ou melhor, em seis bounded contexts, um para cada intenção de negócio (Vendas, Entregas, Estoque etc.). Agora cada bounded context possui uma entidade Produto. Cada versão da entidade Produto é diferente nos seis bounded contexts existentes. A entidade Produto possui comportamentos que atendem necessidades específicas de seu bounded context, a única coisa em comum entre todas as entidades Produto é sua identidade, o ProdutoId no caso. A identidade em comum vai ajudar na persistência e na comunicação entre os bounded contexts.

Mudando um pouco de cenário imagine uma entidade chamada Funcionário, esta entidade representa o colaborador da empresa dentro da aplicação. No bounded context “Recursos Humanos” a entidade Funcionário possui uma modelagem que atende comportamentos como férias, salário, rescisão etc. No bounded context “TI” esta entidade possui uma modelagem que atende comportamentos como login, troca de senha, permissões etc.

Quando se pergunta sobre um funcionário no departamento de TI este está ligado a um usuário e suas responsabilidades dentro do sistema, quando se pergunta sobre um funcionário dentro do RH este está ligado a um colaborador da empresa. É a mesma pessoa, porém dentro da aplicação possui intenções diferentes e é baseada nas intenções que o seu domínio deve ser delimitado em contextos. Não tem necessidade nenhuma a entidade Funcionário do o bounded context de TI ter acesso a salário, reajustes e etc.

Os Bounded Contexts fornecem aos membros das equipes de desenvolvimento um claro entendimento do que deve ser consistido e desenvolvido independentemente.

Representar a mesma entidade em diversos bounded contexts não seria duplicar o código?
De forma alguma. Duplicar código é ter a mesma responsabilidade em trechos de código diferentes. Neste caso existe uma segregação de comportamentos e intenções de uma entidade conforme o contexto em que ela está. Não importa se a entidade é persistida na mesma tabela ou em tabelas diferentes, neste caso ambos os cenários são aceitos.

Características importantes de um bounded context

  • Cada bounded context pode possuir sua própria abordagem de arquitetura. Camadas de aplicação, persistência, infra-estrutura e etc.
  • A arquitetura de um bounded context não precisa estar necessariamente no padrão DDD (Domain Model) pode ser um modelo mais simples de 3 camadas, pode implementar CQRS, Event Sourcing e etc.
  • Cada bounded context pode possuir um meio próprio de persistência, sendo ele relacional, NoSQL, em memória / cache e etc.
  • Os bounded contexts podem se comunicar entre si de diversas maneiras, inclusive utilizando eventos de domínio “Domain Events” conectados em um “Event Bus”.
  • Cada bounded context possui sua própria Ubiquitous Language.
  • Cada bounded context pode ser desenvolvido por um time de desenvolvedores diferente. Não existe necessidade de um único time conhecer a implementação de todos os contextos, pelo contrário, por motivos de segurança o fonte de um bounded context pode ser restrito a um time específico.

Patterns de relacionamento entre bounded contexts

Existem diversos patterns que descrevem o tipo de relacionamento entre os bounded contexts:

  • Shared Kernel
    Um contexto compartilhado entre outros contextos, o shared kernel é um tipo de contexto onde N bounded contexts dependem dele, uma espécie de Core, este tipo de contexto não pode ser alterado sem consultar todos os times de desenvolvimento que dependem dele.
  • Customer/Supplier
    Contextos customer dependem de contextos supplier.
    A equipe downstream atua como cliente (customer) da equipe upstream (supplier). As equipes definem testes de aceitação automatizados que validam as interfaces que a equipe upstream fornecem. A equipe upstream pode então fazer alterações em seu código sem medo de quebrar alguma coisa da equipe downstream.
  • Conformist
    É o cenário onde as equipes downstream e upstream não estão mutuamente alinhadas e a equipe downstream precisa atender o negócio com o que a equipe upstream fornece mesmo não estando de acordo com as necessidades. A equipe downstream precisa aceitar este fato, se conformar com isto.
  • Partner
    Neste cenário duas equipes possuem dependências mútuas em seus contextos e precisam somar esforços de modelagem para se atenderem mutuamente.
  • Anti Corruption Layer
    Neste cenário a equipe downstream desenvolve uma camada adicional anti-corrupção para se comunicar com o contexto upstream, é o cenário típico onde o supplier é um sistema legado ou uma API mal desenvolvida.

Domain Model Pattern

É um padrão muito indicado para atender um bounded context, o domain model pattern atende diversas convenções do DDD como:

  • Aggregate Object
    Uma entidade que é a raiz agregadora de um processo do domínio que envolve mais de uma entidade.
  • Domain Model
    Uma entidade do domínio, possui estados e comportamentos, lógica de negócio, getters e setters AdHoc, etc.
  • Value Object
    Um objeto que agrega valor às entidades, não possui identidade e é imutável.
  • Factory
    Classe responsável por construir adequadamente um objeto / entidade.
  • Domain Service
    Serviço do domínio que atende partes do negócio que não se encaixam em entidades específicas, trabalha com diversas entidades, realiza persistência através de repositórios e etc.
  • Application Service
    Serviço de aplicação que orquestra ações disparadas pela camada de apresentação e fornece DTOs para comunicação entre as demais camadas e para o consumo da camada de apresentação.
  • Repository
    Uma classe que realiza a persistência das entidades se comunicando diretamente com o meio de acesso aos dados, é utilizado apenas um repositório por agregação.
  • External Service
    Serviço externo que realiza a consulta/persistência de informações por meios diversos.

E o código como fica?
O mais importante é entender os conceitos, uma vez que cada um deles estão claros escrever o código é a parte mais fácil. Num próximo material eu trarei uma implementação destes conceitos.

Resumindo

O conceito de bounded context deve ser aplicado buscando delimitar os comportamentos do domínio com base em suas intenções, dando claro entendimento do que precisa ser desenvolvido de forma independente e compartilhada.

Trabalhar com DDD não significa abordar uma arquitetura dividida em camadas responsáveis sendo uma delas a camada de domínio, significa trabalhar a complexidade do negócio em uma modelagem que atenda as necessidades de forma clara, coesa e respeitando as boas práticas de desenvolvimento.

Vaughn Vernon em seu livro Implementing Domain-Driven Design aborda o conceito de arquitetura hexagonal utilizando DDD, CQRS, Event Sourcing, Domain Events, SOA e etc. Neste livro é possível entender que cada bounded context pode possuir sua própria arquitetura hexagonal ou implementar alguma outra abordagem de arquitetura como já foi citado anteriormente neste artigo.

O DDD desde 2003 vem evoluindo bastante e já não está mais preso nos conceitos iniciais, está mais aberto e flexível, permitindo diversas abordagens de arquitetura entre outras implementações como eventos e mensagerias para integrações.

Referências


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos design patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

10 Motivos para ir ao ASP.NET Brasil Conference 2016

Participar de eventos técnicos como o ASP.NET Brasil Conference é algo que todo desenvolvedor deve fazer, pois é a melhor maneira de absorver conhecimento de forma prática e manter-se sempre atualizado.

Eventos técnicos são ótimas fontes de conhecimento para quem deseja se atualizar de forma rápida, as vezes é muito difícil encontrar um evento que seja focado em atender um conhecimento específico e é por este motivo que apresento 10 motivos para ir ao ASP.NET Brasil Conference 2016.

ASP.NET Brasil Conference 2016

 1 – Atualização tecnológica

O ASP.NET Brasil Conference é um evento planejado e focado em atender a necessidade de atualização tecnológica que todo desenvolvedor possui. Estar atualizado é o segredo para o crescimento de carreira e para o surgimento de novas oportunidades de trabalho.

2 – Um novo mercado para o .NET

O .NET e o ASP.NET entraram em uma nova era! Um novo stack totalmente reescrito do zero, multi-plataforma, mais de 2000% mais rápido e focado em escalabilidade em nuvem.
Com esta nova era do .NET o mercado que conhecemos irá mudar muito, inúmeras novas oportunidades irão surgir e você precisa estar preparado.

3 – Grade de palestras focada

A grade de palestras do ASP.NET Brasil Conference foi modelada com o objetivo de fornecer o máximo de conteúdo necessário para lhe atualizar nesta nova era do .NET, todas as palestras irão apresentar de forma prática e teórica as grandes novidades e novidade é o que não falta.

4 – Palestrantes de grande reconhecimento

Todos os palestrantes são profissionais de grande reconhecimento no mercado e que trabalham no dia-a-dia com as tecnologias que irão apresentar. Tivemos um grande cuidado em selecionar os palestrantes conforme seu foco técnico para lhe oferecer uma grande experiência de troca de conhecimentos.

5 – Networking

Teremos 600 participantes, é uma ótima oportunidade de conhecer novos profissionais e gerar diversas oportunidades. Buscando um novo emprego? Procurando a pessoa certa para lançar uma Startup? Gostaria de fazer novas amizades dentro de sua área? O ASP.NET Brasil Conference é uma ótima oportunidade!

6 – Aprender a vender

Já aprendeu sobre uma nova tecnologia, gostou dela mas na hora de apresentar na empresa faltaram palavras para vender a ideia? No ASP.NET Brasil Conference todas as palestras são focadas no cenário ideal para sua aplicação, assim você poderá aumentar seu repertório técnico para propor as inovações tecnológicas que sua empresa precisa.

7 – Melhor custo / benefício

O quanto de investimento financeiro seria necessário para aprender sobre todos os assuntos abordados na grade de forma independente? Calcule o valor de sua hora, livros e até cursos que poderiam ser necessários para adquirir o conhecimento desejado.
Investir em um evento de um dia é uma ótima opção que com certeza lhe poupará muito tempo e dinheiro.

8 – Se envolver com a comunidade técnica

A comunidade técnica .NET é muito unida e sempre contamos com pessoas bem intencionadas para ajudar numa dúvida ou opinião, fazer parte da comunidade é uma ótima maneira de criar novos contatos e fazer um ótimo networking.
No ASP.NET Brasil Conference teremos muitos colaboradores da comunidade técnica presentes.

9 – Brindes e prêmios

É muito bom ir a um evento e ganhar camiseta, adesivos e outros brindes da tecnologia que trabalhamos. É melhor ainda quando além disso levamos para casa um prêmio de alto valor. No ASP.NET Brasil Conference 2015 distribuímos camisetas, adesivos e uma bag para todos os participantes, também sorteamos 1 Xbox One e 2 celulares Lumia. Para este ano divulgaremos os brindes e prêmios em breve.

10 – Local privilegiado

Escolhemos uma estrutura muito bem localizada para facilitar o acesso de todos ao evento. Além da localização também priorizamos o conforto, teremos um grande telão, cadeiras confortáveis e uma disposição em formato de cinema / teatro para ninguém perder um detalhe do conteúdo. Confira abaixo uma visão 360º do local do evento.

O que está esperando? Junte se a nós neste grande evento!

Confira nossa agenda, palestrantes e demais detalhes no nosso site:
www.aspnetbr.com

Estamos com um valor promocional para compra antecipada, seja rápido para garantir o seu, utilize o sistema de compras abaixo para agilizar sua inscrição.
Espero lhe ver la! 

Microsoft MVP 2016

O ano de 2016 começou novamente com ótimas notícias, fui novamente reconhecido como Microsoft MVP.

É sempre uma felicidade muito grande receber este prêmio, apesar de ser minha terceira vez consecutiva a felicidade é sempre a mesma.

Microsoft MVP 2016

Existem muitos motivos para me motivar fazer parte para sempre deste programa e quero destacar os quatro principais:

  • Estar em contato direto um time muito seleto de profissionais em todo o mundo.
  • Acesso ao time de produto / desenvolvimento da Microsoft.
  • Atender ao MVP Summit em Redmond sede global da Microsoft.
  • Ser reconhecido no mercado como um profissional de destaque.

Existe um quinto ótimo motivo que é receber os mimos da nomeação, faz qualquer um querer fazer parte 🙂

MVP 2014, 2015, 2016

Novidade

Neste ano de 2016 eu deixei de ser MVP em ASP.NET e passei a ser MVP em Visual Studio and Development Technologies. Essa mudança faz parte da nova taxonomia da premiação que foi atualizada, confira o anúncio oficial.

Isto não significa que deixarei falar de ASP.NET, pelo contrário, porém contribuições em outras tecnologias também serão válidas para o programa.

O ano de 2015 foi muito importante para mim, veja minha retrospectiva, e eu atribuo grande parte destas conquistas ao fato de ser reconhecido como Microsoft MVP.

Quem quiser conferir todas minhas contribuições no ano de 2015 utilize este link, ele também é válido para buscar MVP’s por nome, país e competência.

Para quem quiser saber mais sobre o programa:

Gostaria de agradecer a todos pelas milhares de visitas, feedbacks, agradecimentos e etc. Com certeza é esse meu maior motivador, colaborar e contribuir com o crescimento e especialização da nossa área.

Um grande abraço!

Introdução ao ASP.NET Core 1.0

Estes últimos dois anos foram de muitas mudanças e novidades para o ASP.NET, que agora ganhou um novo nome. Conheça o ASP.NET Core 1.0.

O ASP.NET Core 1.0 é uma novidade de baixo impacto tecnológico, trata-se do novo nome do novo ASP.NET.

ASP.NET Core 1.0

Desde que anunciado o novo ASP.NET já tivemos alguns nomes, vamos recapitular:

  • ASP.NET vNext
  • ASP.NET 5
  • ASP.NET Core 1.0

Por que não ASP.NET 5?
O nome ASP.NET 5 não foi muito bem recebido por muitos colaboradores da comunidade, gerou diversas reclamações como podemos ver nesta issue do GitHub. O ASP.NET 5 não é apenas uma nova versão do ASP.NET e sim um ASP.NET totalmente novo, reescrito para trabalhar de forma diferente do clássico ASP.NET que já tem 15 anos de existência.

Outro fato que causou confusão foi o MVC 6. ASP.NET 5, MVC 6, Razor 4, SignalR 3, Identity 3, Entity Framework 7 e .NET Core 5. Quantos números para uma tecnologia totalmente nova certo? Para deixar muito claro que o novo ASP.NET substitui o antigo ele precisou mudar de nome outra vez.

Não foi apenas o ASP.NET que mudou de nome:

  • ASP.NET 5 => ASP.NET Core 1.0
  • ASP.NET MVC 6 => ASP.NET Core MVC 1.0
  • .NET Core 5 => .NET Core 1.0
  • Entity Framework 7 => Entity Framework Core 1.0 (ou EF Core 1.0)

Algumas tecnologias citadas acima não tiveram anúncios de novos nomes, porém acredito que possa surgir mais novidades.

Por que 1.0? É um novo ASP.NET, logo todo novo conceito precisa surgir de uma versão inicial, pois não é uma continuidade da tecnologia, é uma nova tecnologia.

Algumas dúvidas podem surgir:

Acompanhei todas as mudanças do ASP.NET 5 agora vou precisar aprender tudo de novo?
Não! Esta mudança anunciada reflete apenas na mudança do nome.

Estou começando a estudar ASP.NET agora, qual versão devo estudar?
Eu recomendo fortemente que estude o ASP.NET MVC 5 e o ASP.NET Core 1.0. O primeiro para atender uma demanda enorme de mercado que não vai sumir em menos de 3 anos e o segundo para poder trabalhar com a nova plataforma em futuros projetos.

Qual a diferença do ASP.NET MVC 5 para o ASP.NET Core 1.0?
É um novo ASP.NET porém ambos trabalham com o MVC, logo a forma de desenvolver não muda muito, o que muda é a tecnologia do stack do ASP.NET, a maneira que ele funciona. Certamente tem muitas mudanças de um para outro, mas conhecendo um é muito fácil entender o outro.

Vou começar um projeto agora, devo desenvolver em ASP.NET Core 1.0?
Uma solução de mercado deve ser escrita com uma tecnologia madura, bem testada e que seja pronta. O ASP.NET MVC 5 (ASP.NET 4.6) ainda é a melhor opção neste momento, pois ainda não temos uma versão 1.0 (RTM) para o ASP.NET Core 1.0, ela virá em breve porém mesmo assim não estará completa como expliquei neste artigo.

Recomendo que utilizem o ASP.NET Core 1.0 em projetos de estudo, pois a viabilidade comercial de uma aplicação não pode depender de possíveis bugs / limitações de uma nova tecnologia.

Por onde começar com o ASP.NET Core 1.0?
Recomendo utilizar o guia do site Get ASP.NET.

Ainda vale a pena estudar ASP.NET WebForms?
Existe uma grande demanda de mercado para WebForms, cerca de 50% de todas aplicações ASP.NET ainda são WebForms, logo se pretende atender a demanda de manutenção em aplicações WebForms é necessário conhecer sim. Minha recomendação é focar os estudos em ASP.NET MVC 5 e ASP.NET Core 1.0. Não recomendo criar novas aplicações em WebForms. Estude apenas se existir a necessidade.

O WebForms faz parte do novo ASP.NET?
Não. O WebForms está pronto e faz parte do ASP.NET 4.6, não irá fazer parte do ASP.NET Core 1.0, pois é tecnologicamente incompatível, a única forma de desenvolvimento em ASP.NET Core 1.0 é o MVC.


O ASP.NET e toda plataforma de desenvolvimento .NET está passando por uma grande revolução para atender o mercado com excelência, segurança e performance. Este é apenas o primeiro passo de uma longa e nova jornada. Mantenha-se atento às novidades, elas vão surgir em um espaço de tempo cada vez menor.

Eu também fiz um vídeo de 8 minutos sobre este assunto, vale a pena conferir:

* Assine meu canal no Youtube 🙂

Referências


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

SOLID – OCP e Extension Methods

Extension Method é um recurso presente desde o C# 3.0 e que facilita bastante o uso do OCP – Open Closed Principle.

SOLID - Teoria e Prática

Os extension methods permitem que você adicione comportamentos em classes existentes sem precisar modificá-las. Os extension methods são um tipo especial de método estático, porém são chamados como se fossem métodos de instância na classe estendida.

Para o código escrito em .NET não há nenhuma diferença entre chamar um extension method ou os métodos realmente definidos em uma classe.

Como um recurso tão importante como este pode passar desconhecido por diversos desenvolvedores? É por este motivo que escrevi este artigo.

No SOLID os extension methods são perfeitos para aplicar OCP – Open Closed Principle de uma forma muito natural e proporcionando um código de baixo acoplamento.
Caso você não conheça todos os princípios do SOLID assista este tutorial completo.

Para demonstrar mais facilmente como utilizar os extension methods e aplicá-los ao OCP eu gravei um vídeo de 18 minutos onde rapidamente explico tudo.

* Assine meu canal no Youtube 🙂

O código fonte desta solução está disponível no GitHub

Referências


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)