Revisão de arquitetura

Para fazer revisões de arquitetura devemos considerar alguns pontos importantes.

As soluções/projetos devem estar adequadas ao um padrão especifico, para isso deve-se validar periodicamente a estrutura das mesmos para que sua evolução seja o mantida dentro do padrão, reduzindo o impacto com relação a manutenção/sustentação.

Caracteristicas implícitas

As implementações devem ser analisadas levando em consideração os seguintes aspectos:

• O que esta sendo feito:
  • Satisfaz os casos de uso/requisitos do sistema;
  • Resiste a mudanças efetuadas no ambiente de implementação;
  • É de fácil manutenção e entendimento;
• O procedimento de implementação é claro;
• Tem fácil adaptação a possíveis mudanças validas efetuadas nos requisitos (Nível de dimensionamento mais complexo).

Objetivos diretos

Observar com precisão os seguintes pontos:

• Dimensionar falhas no disign da solução;
• Manter a consistência e integridade na arquitetura das aplicações;
• Identificar oportunidade de:
  • Refactory;
  • Reutilização de código;
  • Criação de componentes;
• Observar se as fronteiras das camadas são respeitadas no design da aplicação;
• As camadas estão sendo utilizadas para encapsular as fronteiras conceituais entre os tipos de serviço, Ex:
  • Negocio: domínio da solução;

• Facade: aplicação, distribuição de fluxos entre web e negocio e demais camadas;
• Web: interface com o usuário;
• Infra: cross-cutting, camada transversal que serve as demais;
• Repositorio: persistência dos dados;
• A abstração das camadas  facilita a compreensão do design;

• Detectar incopatibilidade entre os casos de uso:
  • Design execessivo;
  • Requisitos não realistas/ausentes;
• Analisar aspectos não-funcionais:
  • Desempenho;
  • Confiabilidade;
  • Segurança;

Sugestão de verificação

São necessárias algumas verificações para garantir a qualidade dos fontes em e da estrutura da aplicação, são eles:

• Mecanismos de Arquitetura/Design
  • Furo de camadas;
  • Documentos/arquivos dispersos;
  • Recuperação ou tratamento de erros;
  • Exibição e interfaces comuns (exibição em janelas, captura de dados, condicionamento de sinais etc.);
  • Para componentes TCE, esta utilizando os pacotes nuGet;
  • Assembly information;
  • Nomenclaturas
    • Pastas;
    • Projetos;
    • Classes;
    • Interfaces;
    • Arquivos;
    • Mensagens;
  • Nível de abstração de componentes;
• Qualidade:
  • Cobertura de código com relação aos testes unitários;
  • Testes de carga;
  • Testes de regressão;
  • Testes de de interface (Automatizados);
  • (…)
• Código fonte:
  • Nomespaces;
  • Duplicação de código;
  • “Using” desnecessário;
  • Nomes de variáveis;
  • Heranças;
  • Visibilidade de métodos;
  • Classes por arquivo (Deve ser somente uma classe);
  • Poluição do código:
    • Comentários desnecessários;
    • Metodos sem nenhuma referência;
    • Métodos com escopos vazios;
    • Mensagens/strings fora do resource;
  • Padrões SOLID;
    • Reponsabilidade única;
      • Linhas de código por método;
    • Fechado para alteração, aberto para extenção;
      • Complexidade do método;
    • Deve ser possível substituir uma classe base por suas classes derivadas em quanquer ponto do código.
      • Uso da classe base e herança da forma correta;
    • Classes dependem somente de interfaces e não de classes concretas;
      • Uso do NEW dentro das classes;
    • Injeção de dependência / Inversão de controle;
      • Construtor com as interfaces necessárias;

 

Verificação adicional

A verificação adicional é para garantir a evolução adequada das estruturas paralelas relacionas ao projeto como documentação, banco de dados e versionador de código;

• Repositorio (Team Explorer)
  • Nomenclatura
    • Pastas;
    • Branches;
  • Banco de dados
    • Nomenclatura
      • Tabelas;
      • Views;
      • StoredProcedures;
      • Funções;
      • Colunas;
      • FK, PK, UK;
    • Normalização adequada;
  • Documentação
    • Técnica (DA – Documento de arquitetura)
      • Visão logica (diagrama de sequência);
      • Visão dos dados (DER);
    • Negocio (UC – Casos de uso);

Anúncios

Padrões

SOLID

Class Design
SRP (Single Responsability Principle / Responsabilidade única): Uma classe ou método deve ter uma única responsabilidade. Deve ter apenas uma razão para mudar.

OCP (Open Closed Principle / Aberto fechado): Uma classe deve sempre estar aberta para EXTENÇÃO e fechada para MODIFICAÇÃO.

LSP (Liskov Substitution Principle / Substituição Liskov): Deve ser possível substituir uma classe base por suas classes derivadas em quanquer ponto do código.

ISP (Interface Segregation Principle / Segregação de interface): Clientes não devem ser obrigados a depender de interfaces que eles não utilizam. Muitas interfaces de um cliente especifico é melhor do que uma interface de uso geral.

DIP (Dependecy Inversion Principle / Inversão dependência): Módulos de alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstrações. Abstrações não devem depender de detalhes, detalhes devem depender de abstrações, por exemplo, uma classe deve depender de uma interface ou classe abstrata e não de uma classe concreta.

Package Cohesion

REP (The Reuse Release Equivalency Principle)
CCP (The Common Closure Principle Principle)
CRP (The Common Reuse Principle)

Package Coubling
ADP (The Acyclic Dependencies Principle)
SDP (The Stable Dependencies Principle)
SAP (The Stable Abstractions Principle)

GRASP

Padrões básicos

Information Expert (Especialista de informação): Atribuir uma responsabilidade ao especialista da informação. Classe que possui a informação necessária para cumpri-la.

Creator (Criador): Um objeto deve ser criado por outro que o possua como parte (agregação) ou esteja fortemente associado a ele
High coesion (Alta coesão): Atribuir uma responsabilidade para que a coesão se mantenha alta

Low coupling (Baixo acoplamento): ­ Atribuir uma responsabilidade para que o acoplamento mantenha-se fraco

Controller (Controlador): Atribuir responsabilidades para receber ou lidar com um evento do sistema.
• uma classe que representa todo o sistema ou subsistema (façade controller)
• uma classe que representa cenário de caso de uso (controlador de caso de uso ou de sessão)

Padrões avançados

Polymorphism (Polimorfismo): Não use lógica condicional para realizar alternativas diferentes baseadas em tipo. Atribua responsabilidades ao comportamento usando operações polimórficas.

Pure Fabrication (Invenção pura): Atribuir um conjunto altamente coesivo de responsabilidades a uma classe artificial que não representa um conceito do domínio do problema.

Indirection (Indireção): Atribua a responsabilidade a um objeto intermediário para mediar as mensagens entre outros componentes ou serviços para que não sejam diretamente acoplados.

Protected Variations (Variação protegida): Identificar pontos de variação ou instabilidade potenciais e atribuir responsabilidades para criar uma interface estável em volta desses pontos.

GoF

Creational Patterns
Abstract Factory: Creates an instance of several families of classes
Builder: Separates object construction from its representation
Factory Method: Creates an instance of several derived classes
Prototype: A fully initialized instance to be copied or cloned
Singleton: A class of which only a single instance can exist

Structural Patterns
Adapter: Match interfaces of different classes
Bridge: Separates an object’s interface from its implementation
Composite: A tree structure of simple and composite objects
Decorator: Add responsibilities to objects dynamically
Facade: A single class that represents an entire subsystem
Flyweight: A fine-grained instance used for efficient sharing
Proxy: An object representing another object

Behavioral Patterns
Chain of Resp.: A way of passing a request between a chain of objects
Command: Encapsulate a command request as an object
Interpreter: A way to include language elements in a program
Iterator: Sequentially access the elements of a collection
Mediator: Defines simplified communication between classes
Memento: Capture and restore an object’s internal state
Observer: A way of notifying change to a number of classes
State: Alter an object’s behavior when its state changes
Strategy: Encapsulates an algorithm inside a class
Template: Method Defer the exact steps of an algorithm to a subclass
Visitor: Defines a new operation to a class without change

 

Referência:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

 

Microservices

APLICAÇÕES MONOLÍTICAS

• Fornece Macro-funcionalidades;
• Toda a capacidade do negocio/domínio esta em uma mesma funcionalidade ou serviço;
• Aplicação dividida em camadas;
• Arquitetura dependente;
• Deploy simples;
• Hospedado em um servidor especifico;
• Desenvolvimento altamente dependente da plataforma;
• Escalabilidade vertical;
• Evolução comprometida;
• Banco de dados integrado:
• Deploy centralizado:

APLICAÇÕES EM MICRO-SERVIÇOS

• Fornece Micro-funcionalidade;
• Isola responsabilidades;
• Solução granular;
• Divisão de responsabilidades entre projetos/serviços;
• Alta disponibilidade e escalabilidade;
• Escalabilidade na capacidade de negocio;
• Altamente desacoplada;
• Solução segmentada e distribuída;
• A aplicação não é desenvolvida em termos de projetos e sim em serviços/produtos;
• Monitoramento especifico por serviço;
• Pode ser desenvolvimento em varias plataformas ao mesmo tempo;
• Dados decentralizados;
• Banco de dados segmentados;
• Serviços específicos podem compartilhar bancos de dados distintos;
• A integração entre serviços pode ser feita através de messageria (RabbitMQ);
• Deploy descentralizado:

• Componentização via serviços;

 

Referência:
http://martinfowler.com/articles/microservices.html
http://martinfowler.com/microservices
http://microservices.io/

Padrões de projeto – SOLID

Em arquitetura de software devemos seguir alguns padrões para que nossos projetos possam crescer de forma segura, facilitando a manutenção do código e expansão do projeto. A seguir vou demonstrar um conceito muito conhecido de cinco princípios que devem ser seguidos para que o seu projeto tenha um nível alto de entendimento.

S O L I D

Single Responsability Principle – SRP (Responsabilidade única): Parte do principio que uma classe ou método deve ter uma única responsabilidade. Deve ter apenas uma razão para mudar.

Open Closed Principle – OCP (Aberto fechado): Uma classe deve sempre estar aberta para EXTENÇÃO e fechada para MODIFICAÇÃO.

Liskov Substitution Principle – LSP (Substituição Liskov): Deve ser possível substituir uma classe base por suas classes derivadas em quanquer ponto do código.

Interface Segregation Principle – ISP (Segregação de  interface): Clientes não devem ser obrigados a depender de interfaces que eles não utilizam. Muitas interfaces de um cliente especifico é melhor do que uma interface de uso geral.

Dependecy Inversion Principle – DIP (Inversão dependência): Módulos de alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstrações. Abstrações não devem depender de detalhes, detalhes devem depender de abstrações, por exemplo, uma classe deve depender de uma interface ou classe abstrata e não de uma classe concreta.