Arquitetura de software, para mim, não é uma disciplina separada de Salesforce - é o nível de decisão que fica acima dela. A pergunta não é "como implementar isso", mas "que sistema esse negócio precisa ter daqui a dois anos, dado o que sabemos hoje".

Isso envolve decidir fronteiras: o que fica dentro da plataforma, o que vira um serviço externo, onde o acoplamento é aceitável e onde ele vira um problema de manutenção permanente. Nenhuma dessas decisões é gratuita - todas trocam velocidade por rigidez ou flexibilidade por complexidade, e o trabalho de arquiteto é tornar essa troca explícita, não escondê-la atrás de um padrão de mercado aplicado sem questionar.

Prefiro arquitetura que quem implementa consegue explicar de volta - se uma decisão só faz sentido para quem a desenhou, ela provavelmente está sofisticada demais para o problema real. Isso vem diretamente de ter passado por administração, desenvolvimento e consultoria antes de chegar em arquitetura: sei o custo de herdar uma decisão que parecia elegante no quadro branco.

Como consultor independente, aplico essa forma de pensar em contextos fora do Salesforce também - tornar decisões técnicas rastreáveis e revisáveis não é específico de uma plataforma.