Principais problemas

• Visão de futuro:
  A maioria dos softwares é feita pensando no agora e não no futuro

• Limites bem definidos:
  Não misturar as regras de negócio com framework, não deixar o app fortemente acoplado com bibliotecas terceiras

• Troca e adição de componentes:
  Tudo que for desenvolvido deve ser facilmente trocado

• Escala:
  Cada aplicação relacionada (cache, banco de dados, ...etc) deve ficar em seu próprio servidor

• Otimizaçõ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 futuro

• Preparado 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