Principais problemas
Visão de futuro:
A maioria dos softwares é feita pensando no agora e não no futuroLimites bem definidos:
Não misturar as regras de negócio com framework, não deixar o app fortemente acoplado com bibliotecas terceirasTroca e adição de componentes:
Tudo que for desenvolvido deve ser facilmente trocadoEscala:
Cada aplicação relacionada (cache, banco de dados, ...etc) deve ficar em seu próprio servidorOtimizações frequentes:
Todo software vai ter debito técnico mas é preciso sempre otimizar para não deixar um grande debito que vai ser mais complicado de solucionar no futuroPreparado para mudanças:
Ex: Se eu quiser mudar um provedor de dados extras no cadastro ele tem que estar desacoplado para que seja possível mudar facilmente
Arquitetura vs Design
Atividades relacionadas a arquitetura de software são sempre de design. Entretanto, nem todas atividade de design são sobre arquitetura. O objetivo primário da arquitetura de software é garantir que os atributos de qualidade, restrições de alto nível e os objetivos do negócio, sejam atendidos pelo sistema. Qualquer decisão de design que não tenha relação com este objetivo não é arquitetural. Todas as decisões de design para um componente que não sejam “visíveis” fora dele, geralmente, também não são.
Fonte: Elemar Júnior (https://eximia.co/quais-sao-as-diferencas-entre-arquitetura-e-design-de-software/)
Design é uma decisão micro enquanto Arquitetura se preocupa com o macro, o Design pode ser exemplo como definir o nome das variveis ou até mesmo SOLID que são regras de design, então dependendo Design pode ou não interferir na arquitetura
Arquitetura Hexagonal
Permite que uma aplicação seja igualmente desenvolvida para os usuários, programas, testes automatizados ou scripts bash, e para ser desenvolvida e testada de forma isolada dos seus eventuais devices e bancos de dados de produção
Cockburn
Perceba que temos uma aplicação no centro e diversos adaptadores para a comunicação externa da aplicação
É como em uma casa onde não ligamos diretamente os equipamentos na rede elétrica da casa e sim em tomadas que nesse caso servem como adaptadores
No lado esquerdo da aplicação temos os clientes e no lado direito temos os servidores, e a ideia é que a aplicação utilize os servidores para responder os clientes, sendo que todos vão estar conectados aos adaptadores
Utilizando os conceitos de inversão de dependências, os clientes vão sempre se comunicar através de interfaces enquanto os bancos de dados por exemplo vão sempre se comunicar com os DataReaders.
Observações
A arquitetura hexagonal não define padrão de como deve ser criado o software
Apesar de Arquitetura hexagonal, clean arch e arquitetura onion terem o mesmo principio de separar a aplicação da camada de negocio, a principal diferença da arquitetura hexagonal é que ela não define o padrão de como criar o software
Top comments (0)