segunda-feira, 9 de maio de 2016

Clean Architecture

Ao separar o software em camadas, e em conformidade com a regra de dependência, você vai criar um sistema que é intrinsecamente testável, com todos os benefícios que isso implica.
Quando qualquer uma das partes externas do sistema tornam-se obsoletos, como o banco de dados, ou o framework web, você pode substituir os elementos obsoletos com um mínimo de trabalho. 
Círculos internos definem interfaces.
Círculos externos implementam as interfaces.
A arquitetura de software deve ser: 
  • Independente de Framework
  • Estável (business pode ser testado sem influência de UI ou outro agente externo)
  • Independente de Banco
  • Independente de agentes externos (regras de negocio puras) 

 

The Dependency Rule

Esta regra diz que as dependências de código fonte só pode apontar para dentro. Nada em um círculo interno pode saber alguma coisa sobre alguma coisa em um círculo externo. Isso inclui, funções, classes. variáveis, ou qualquer outra entidade.

Entities

Entidades encapsula regras de negócio da empresa. Uma entidade pode ser um objeto com métodos, ou pode ser um conjunto de estruturas de dados e funções. Não importa, desde que as entidades podem ser utilizados em muitas aplicações diferentes na empresa.

Use Cases


Os softwares dessa camada contém regras de negócio específicas de aplicação. Ele incorpora e implementa todos os casos de uso do sistema. Esses casos de uso orquestrar o fluxo de dados de e para as entidades, e direcionar essas entidades a utilizar as suas regras de negócio para empresas, para atingir os objetivos do caso de uso.

Interface Adapters

Os softwares nessa camada é um conjunto de adaptadores que convertem os dados do formato mais conveniente para os casos de uso e entidades, para o formato de um agente externo, como o banco de dados etc. Os apresentadores, views e controllers pertencem todos aqui. 

Nenhum código dentro deste círculo deve saber alguma coisa sobre o banco de dados.

Frameworks and Drivers.

A camada mais externa é geralmente composto de estruturas e ferramentas, tais como banco de dados, a Web Framework, etc Geralmente você não escrever muito código nesta camada diferente do código de cola que se comunica com o próximo círculo dentro. 

Boundaries. 

Podemos considerar tudo aquilo que define comunicação entre as fronteiras.

Por exemplo: Request Model, Response Model , fazem a comunicação entre os modelos da entidade com a View.
Referências:

Design by contract, implementando primeiro um contrato

Design by Contract é baseado em uma poderosa metáfora de como elementos de um sistema de software de interagir uns com os outros, da mesma forma que as empresas colaboram: com base em obrigações ebenefícios mútuos. 
O "cliente" e "fornecedor" concordar com um "contrato" que:
  • O fornecedor deve fornecer um resultado determinado (obrigação) e tem o direito de esperar que o cliente ter satisfeito as condições exigidas (benefício).
  • O cliente deve satisfazer estas condições (obrigação) e tem o direito de obter o resultado (benefício).
  • Ambas as partes devem cumprir determinadas leis e regulamentos gerais, aplicando-se a todos os contratos.
Design by Contract transforma esses elementos em componentes integrais do software: pré-condições (obrigações do cliente, benefícios fornecedor);
Pós-condições (benefícios de cliente, obrigações do fornecedor);
Invariantes (regras gerais). 
Esses conceitos existem em todos os níveis:
  • requisitos
  • projeto
  • implementação
  • teste

Design by Contract revoluciona construção de software por eliminará erros antes que eles têm a oportunidade de prejudicar o software.
Design by Contract fornece:
  • documentação automática, de alta qualidade.
  • quadro integrado para testes específicos e eficazes.
  • a capacidade de comunicar seu projeto sem a necessidade de descrever os detalhes da implementação.
  • um guia claro e simples ao longo de todo o processo de desenvolvimento de software.
Aguardar uma certa condição para garantir que uma informação no módulo de clientes o chame: a pré-condição da rotina — uma obrigação para o cliente, e o benefício do fornecedor (a rotina em si), eliminando casos de executar por outros meios.
  • Garantir uma certa condição de saída: A pós-condição da rotina — uma obrigação do fornecedor, e obviamente um benefício (o maior benefício de chamar a rotina) para o cliente.
  • Manter uma determinada propriedade, assumida na entrada e garantida na saída: uma Classe Constante.
É possível resumir Programação por contrato através de "3 perguntas" que um designer deve-se fazer constantemente:
  • O que isto prevê?
  • O que isto garante?
  • O que isto mantém?
É um desafio para a construção de uma especificação que:
  • é o mais simples possível
  • é o mais claro possível
  • não tem nenhuma ambiguidade
  • é totalmente preciso
  • permite que o leitor ignore completamente os detalhes de implementação (a menos que há um bug)
  • forneça entendimento ao leitor o mais rápido possível, com pouca chance de mal-entendido
 Design By Contract é muito útil para a criação de classes e interfaces. 

Ele pode tanto orientar a descoberta de um design mais robusto.
Referências:

sexta-feira, 6 de maio de 2016

Web Components a new perspective to web development

This new concept it was created jointly by Firefox and Google and promise change some paradigms.
"The component model for the Web called Web Components consists of four pieces designed to be used together to let web application authors define widgets with a level of visual richness not possible with CSS alone, and ease of composition and reuse not possible with script libraries today."
Web Components consist of 4 proposals: 
1. Templates
Templates are parts of DOM that could be reusable, and this Templates will be append to the DOM. That means <img> sources are not downloaded, scripts are not executed until necessary, saving on bandwidth and processing ,and also the script necessary to execute this component in this example querySelector is hidden on the Template to avoid influencing in the other part of the page.
2.Shadow DOM
Shadow DOM provides encapsulation to markup and style, for example a <video> tag , this tag has many scripts to provide functionality . Each of those controls is implemented as a <div> inside of the <video> tag that is actually not accessible for the scripts on the page but is rendered on users screen.
Shadow DOM is a tool that provide to web developer create own component like tag <video> or <img>.
3.Custom Elements 
Custom Elements can react to the DOM lifecycle events. That enables them to have a certain behaviour when they are added to DOM, their attributes change or they are removed from DOM.
Is possibility to create own first-class DOM members (fist-class DOM could be considered <div>,<p>,<br> etc ... ).
4.Imports 
Imports load external resources, such as Templates or Custom Elements. Imported HTML files can contain templates, stylesheets and scripts. They get executed when the import is loaded.
Why do I care about this? 
  • You are a HTM user, this will help you do more advanced this easily.
  • You are a front end dev, you want to reuse components across pages.
  • You build single pages apps and want a better way to organize things.
  • You are interested in the direction that the web platform is heading.
 Unfortunately these components were available just to Google Chrome Canary or for test in jsFiddle.
But is possible use Polymer or Component Kitchen to use web components in another browsers.
Site with discussion and best-practices  http://webcomponents.org
References: